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CHAPTER  1 


INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  [Pro92]  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Compiler  Validation  Capability  (ACVC) .  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation. 

For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to 
[Pro92].  A  detailed  description  of  the  ACVC  may  be  found  in  the  current 
ACVC  User's  Guide  (U689]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (S  U.S.C.  #552).  The  results  of  this  validation  apply 
only  to  the  computers,  operating  systems,  and  compiler  versions  identified 
in  this  repozrt. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  subject  implementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to: 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria  VA  22311 
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1 . 2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

[Pro92]  Ada  Compiler  Validation  Procedures.  Version  3.1,  Ada  Joint 
Program  Office,  August  1992. 

[UG89]  Ada  Compiler  Validation  Capability  User's  Guide.  21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes: 

A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  n2une  identifies  the  class 
to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B 
and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link 
time,  respectively. 

The  executedsle  tests  are  written  in  a  self -checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  when  they 
are  executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13, 
and  the  procedure  CHECK_FILE  are  used  for  this  purpose.  The  package  REPORT 
also  provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK__FILE  is  used  to  check  the  contents  of 
text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  compilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  compiler.  This  behavior  is 
also  verified. 

Class  L  testa  check  that  an  Ada  implementation  correctly  detects  violation 
of  the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors 
are  expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  used  for  this  implmnentation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the 
AVF.  This  customization  consists  of  making  the  modifications  described 
in  the  preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1)  and, 
possibly  some  inapplicable  teats  (see  Section  2.2  and  [U689]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of 
the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added 
to  a  given  host  and  target  computer  system  to  allow 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof. 

Ada  Compiler  Th^  means  for  testing  compliance  of  Ada  implementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 

Capability  user's  guide  and  the  template  for  the  validation  summary 

(ACVC)  report. 

Ada  An  Ada  compiler  with  its  host  computer  system  and  its 

Implementation  target  computer  system. 

Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 

Progr2un  guidance  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  which  carries  out  the 

Validation  procedures  required  to  estadilish  the  compliance  of  an  Ada 
Facility  (AVF)  implementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guidance  for  operations  of  the  Ada  certification  system. 

Organization 
(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC  version, 
an  Ada 

Implementation 

Computer  A  functional  unit,  consisting  of  one  or  more  computers  and 

System  associated  software,  that  uses  common  storage  for  all  or 

part  of  a  program  and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including  arithmetic 
operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A 
computer  system  may  be  a  stand-alone  unit  or  may  consist  of 
several  inter-connected  units. 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 

ISO 

Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementation 

Validation 


Withdrawn 

test 


Fulfillment  by  a  product,  process  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  who  enters  into  an 
agreement  with  an  AVF  which  specifies  the  terms  and 
conditions  for  AVF  services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attainable  on  the  Ada  implementation  for 
which  validation  status  is  realized. 

A  computer  system  where  Ada  source  programs  are  t’-ans formed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  implementation. 

International  Organization  for  Standardization. 

Software  that  controls  the  execution  of  programs  and  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  management.  Usually, 
operating  systems  are  predominantly  software,  but  partial 
or  complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs 
are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  [Pro92]. 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate 
for  this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  an  invalid 
test  objective,  fails  to  meet  its  test  objective,  or 
contains  erroneous  or  illegal  use  of  the  Ada  progranoning 
language. 
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2 . 1  WITHDRAWN  TESTS 


The  following  teata  have 

been  withdrawn  by  the  AVO 

.  The  rationale  for 

withdrawing 

each  teat  ia 

available  from 

either  the 

AVO  or  the 

AVF.  The 

publication 

date  for  thia 

1  liat  of  withdrawn  teats 

is  August  02 

,  1991. 

E28005C 

B28006C 

C32203A 

C34006D 

C3S508I 

C3S508J 

C35508M 

C35508N 

C3S702A 

C35702B 

B4I308B 

C43004A 

C45114A 

C4S346A 

C4S612A 

C45612B 

C4S612C 

C45651A 

C46022A 

B49008A 

B49008B 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

B01B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

C02A23E 

C02A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

B08004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2 . 2  INAPPLICABLE  TESTS 

A  t««t  ia  inapplicabla  if  it  containa  taat  objsctivea  which  are  irrelevant  for 
a  given  Ada  implementation.  Reaaona  for  a  teat 'a  inapplicaUDility  may  be 
aupported  by  documenta  iaaued  by  the  ISO  and  the  AJPO  known  aa  Ada  Commentariea 
and  commonly  referenced  in  the  format  Al-ddddd.  For  thia  implementation,  the 
following  teata  were  determined  to  be  inapplicable  for  the  reaaona  indicated; 
referencea  to  Ada  Commentariea  are  included  aa  appropriate. 
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The  following  285  tests  have  floating-point  type  declarations  requiring  more 
digits  than  SYSTEM. MAX  DIGITS: 


C24113F. .Y 
C35706F. .Y 
C35708F. .Y 
C45241F. .Y 
C45421F. .Y 
C45524F. .Z 
C45641F. .Y 


(20  tests) 
(20  tests) 
(20  tests) 
(20  tests) 
(20  tests) 
(21  tests) 
(20  tests) 


C35705F. .Y 
C3S707F. .Y 
C35802F. .Z 
C45321F. .Y 
C45521F. .Z 
C4S621F. .Z 
C46012F. .Z 


(20  tests) 
(20  tests) 
(21  tests) 
(20  tests) 
(21  tests) 
(21  tests) 
(21  tests) 


The  following  21  tests  check  for  the  predefined  type  SHORT_INTEGER;  for  this 
implementation,  there  is  no  such  type: 


C35404B 

C45412B 

C45611B 

B52004E 

CD7101E 


B36105C 

C45502B 

C45613B 

C55B07B 


C45231B 

C45503B 

C45614B 

BS5B09D 


C45304B 

C45504B 

C45631B 

B86001V 


C45411B 

C45504E 

C45632B 

C86006D 


The  following  20  tests  check  for  the  predefined  type  LONG_INTEGER;  for  this 
implementation,  there  is  no  such  type:  ~ 


C35404C 

C4S502C 

C45613C 

C55B07A 


C45231C 

C45503C 

C45614C 

BSSB09C 


C4S304C 

C4S504C 

C45631C 

B86001W 


C45411C 

C45504F 

C45632C 

C86006C 


C45412C 

C45611C 

B52004D 

CD7101F 


C35404D,  C45231D,  B86001X,  C86006E,  and  CD7101G  check  for  a  predefined  integer 
type  with  a  name  other  than  INTEGER,  LONG^INTEGER,  or  SHORT_INTEGER;  for  this 
implementation,  there  is  no  such  type.  ~ 


C35713B,  C43423B,  B86Q01T,  and  C86006H  check  for  the  predefined  type 
SHORT_FLOAT;  for  this  implementation,  there  is  no  such  type. 


C3S713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a  name 
other  than  FLOAT,  LONG_FLOAT,  or  SHORT_FLOAT;  for  this  implementation,  there  is 
no  such  type.  ~  ~ 


A3S801E  checks  that  FLOAT ' FIRST. .fXOAT' LAST  may  be  used  as  a  range  constraint 
in  a  floating-point  type  declaration;  for  this  implementation,  that  range 
exceeds  the  range  of  safe  numbers  of  the  largest  predefined  floating-point  type 
and  must  be  rejected.  (See  section  2.3.) 


C45531M..P  and  C45532M..P  (8  testa)  check  fixed-point  operations  for  types  that 
require  a  SYSTEM. MAX  MANTISSA  of  47  or  greater;  for  this  implementation, 

MAX  MANTISSA  is  leas~than  47. 


C45536A,  C46013B,  C46031B,  C46033B,  and  C46034B  contain  length  clauses  that 
specify  values  for  'SMALL  that  are  not  powers  of  two  or  ten;  this 
implementation  does  not  support  such  values  for  'SMALL. 

C4S624A..B  (2  tests)  check  that  the  proper  exception  is  raised  if 
MACHINE_OVERFLOWS  is  FALSE  for  floating  point  types  and  the  results  of  various 
floating-point  operations  lie  outside  the  range  of  the  base  type;  for  this 
implementation,  MACHINE_OVERFLOWS  is  TRUE. 

D64005G  uses  17  levels  of  recursive  procedure  calls  nesting;  this  level  of 
nesting  for  procedure  calls  exceeds  the  capacity  of  the  compiler. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
DURATION;  for  this  implementation,  there  is  no  such  type. 

CA2009A,  CA2009C..D  (2  tests),  CA2009F,  and  BC3009C  check  whether  a  generic 
unit  can  be  instantiated  before  its  body  (and  any  of  its  subunits)  is  compiled; 
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this  implementation  creates  a  dependence  on  generic  units  as  allowed  by 
AI-00408  and  AI-00506  such  that  the  compilation  of  the  generic  unit  bodies 
makes  the  instantiating  units  obsolete.  (See  section  2.3.) 

CD1009C  checks  whether  a  length  clause  can  specify  a  non-default  size  for  a 
floating-point  type;  this  implementation  does  not  support  such  sizes. 

CD2A53A  checks  operations  of  a  fixed-point  type  for  which  a  length  clause 
specifies  a  power-of-ten  TYPE 'SMALL;  this  implementation  does  not  support 
decimal  'SMALLs.  (See  section  2.3.) 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length  clauses  to 
specify  non-default  sizes  for  access  types;  this  implement at ion  does  not 
support  such  sizes. 

CD2B15B  checks  that  STORAGE_ERPOR  is  raised  when  the  storage  size  specified  for 
a  collection  is  too  small  to  hold  a  single  value  of  the  designated  type;  this 
implementation  allocates  more  space  than  was  specified  by  the  length  clause,  as 
allowed  by  AI-00558. 

The  following  264  tests  check  operations  on  sequential,  text,  and  direct  access 
files;  this  implementation  does  not  support  external  files: 


CE2102A. .C 

(3) 

CE2102G. .H 

(2) 

CE2102K 

CE2102N. .Y 

(12) 

CE2103C. .D 

(2) 

CE2104A. .D 

(4) 

CE2105A. .B 

(2) 

CE2106A. .B 

(2) 

CE2107A. .H 

(8) 

CE2107L 

CE2108A. .H 

(8) 

CE2109A. .C 

(3) 

CE2110A. .D 

(4) 

CE2111A. .1 

(9) 

CE2115A. .B 

(2) 

CE2120A. .B 

(2) 

CE2201A. .C 

(3) 

EE2201D. .E 

(2) 

CE2201F. .N 

(9) 

CE2203A 

CE2204A. .D 

(4) 

CE2205A 

CE2206A 

CE2208B 

CE2401A. .C 

(3) 

EE2401D 

CE2401E. .F 

(2) 

EE2401G 

CE2401H. .L 

(5) 

CE2403A 

CE2404A. .B 

(2) 

CE2405B 

CE2406A 

CE2407A. .B 

(2) 

CE2408A. .B 

(2) 

CE2409A. .B 

(2) 

CE2410A. .B 

(2) 

CE2411A 

CE3102A. .C 

(3) 

CE3102F. .H 

(3) 

CE3102J. .K 

(2) 

CE3103A 

CE3104A. .C 

(3) 

CE3106A. .B 

(2) 

CE3107B 

CE3108A. .B 

(2) 

CE3109A 

CE3110A 

CE3111A. .B 

(2) 

CE3111D. .E 

(2) 

CE3112A. .D 

(4) 

CE3114A. .B 

(2) 

CE3115A 

CE3119A 

EE3203A 

EE3204A 

CE3207A 

CE3208A 

CE3301A 

EE3301B 

CE3302A 

CE3304A 

CE3305A 

CE3401A 

CE3402A 

EE3402B 

CE3402C. .D 

(2) 

CE3403A. .C 

(3) 

CE3403E. .F 

(2) 

CE3404B. .D 

(3) 

CE340SA 

EE3405B 

CE3405C. .D 

(2) 

CE3406A. .D 

(4) 

CE3407A. .C 

(3) 

CE3408A. .C 

(3) 

CE3409A 

CE3409C. .E 

(3) 

EE3409F 

CE3410A 

CE3410C. .E 

(3) 

EE3410F 

CE3411A 

CE3411C 

CE3412A 

EE3412C 

CE3413A. .C 

(3) 

CE3414A 

CE3602A. .D 

(4) 

CE3603A 

CE3604A. .B 

(2) 

CE3605A. .E 

(5) 

CE3606A. .B 

(2) 

CE3704A. .F 

(6) 

CE3704M. .O 

(3) 

CE3705A. .E 

(5) 

CE3706D 

CE3706F. .G 

(2) 

CE3804A. .P 

(16) 

CE3805A. .B 

(2) 

CE3806A. .B 

(2) 

CE3806D. .E 

(2) 

CE3806G. .H 

(2) 

CE3904A. .B 

(2) 

CE3905A. .C 

(■?) 

CE3905L 

CE3906A. .C 

(3) 

CE3906E. .F 

(2) 

CE2103A,  CE2103B,  and  CE3107A  expect  that  NAME_ERROR  is  raised  when  an  attempt 
is  made  to  create  a  file  with  an  illegal  name;  this  implementation  does  not 
support  the  creation  of  external  files  and  so  raises  USE_ERROR.  (See  section 
2.3. ) 
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2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  102  tests. 


The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 


B22003A 

B24007A 

B24009A 

B25002B 

B32201A 

B33204A 

B33205A 

B35701A 

B36171A 

B36201A 

B37101A 

B37102A 

B37201A 

B37202A 

B37203A 

B37302A 

B38003A 

B38003B 

B38008A 

B38008B 

B38009A 

B38009B 

B38103A 

B38103B 

B38103C 

B38103D 

B38103E 

B43202C 

B44002A 

B48002A 

B48002B 

B48002D 

B48002E 

B48002G 

B48003E 

B49003A 

B49005A 

B49006A 

B49006B 

B49007A 

B49007B 

B49009A 

B4A010C 

354A20A 

B54A25A 

B58002A 

B58002B 

B59001A 

B59001C 

B59001I 

B62006C 

B67001A 

B67001B 

B67001C 

B67001D 

B74103E 

B74104A 

B74307B 

B83E01A 

B85007C 

B85008G 

B85008H 

B91004A 

B91005A 

B95003A 

B95007B 

B95031A 

B95074E 

BAIOOIA 

BC1002A 

BC1109A 

BC1109C 

BC1206A 

BC2001E 

BC3005B 

BC3009C 

BD2A06A 

BD2B03A 

BD2D03A 

BD4003A 

BD4006A 

BD8003A 

E28002B  was  graded  passed  by  Evaluation  and  Test  Modification  as  directed  by 
the  AVO.  This  test  checlcs  that  pragmas  may  have  unresolvable  arguments,  and  it 
includes  a  check  that  pragma  LIST  has  the  required  effect;  but  for  this 
implementation,  pragma  LIST  has  no  effect  if  the  compilation  results  in  errors 
or  warnings,  which  is  the  case  when  the  test  is  processed  without  modification. 
This  test  was  also  processed  with  the  pragmas  at  lines  46,  58,  70  and  71 
commented  out  so  that  pragma  LIST  had  effect. 

A35801E  was  graded  inapplicable  by  Evaluation  Modification  as  directed  by  the 
AVO.  The  compiler  rejects  the  use  of  the  range  FLOAT 'FIRST. .FLOAT 'LAST  as  the 
range  constraint  of  a  floating-point  type  declaration  because  the  bounds  lie 
outside  of  the  range  of  safe  numbers  (cf.  LRM  3.5.7:12). 

C83U30C  and  C86007A  were  graded  passed  by  Test  Modification  as  directed  by  the 
AVO.  These  tests  were  modified  by  inserting  "PRAGMA  ELABORATE  (REPORT);"  before 
the  package  declarations  at  lines  13  and  11,  respectively.  Without  the  pragma, 
the  packages  may  be  elaborated  prior  to  package  Report's  body,  and  thus  the 
packages'  calls  to  function  REPORT. IDENT  INT  at  lines  14  and  13,  respectively, 
will  raise  PROGRAM_ERROR . 

B83E01B  was  graded  passed  by  Evaluation  Modification  as  directed  by  the  AVO. 
This  test  checks  that  a  generic  subprogram's  formal  parameter  naunes  (i.e.  both 
generic  and  subprogram  formal  parameter  names)  must  be  distinct;  the  duplicated 
names  within  the  generic  declarations  are  marked  as  errors,  whereas  their 
recurrences  in  the  subprogram  bodies  are  marked  as  "optional”  errors — except 
for  the  case  at  line  122,  which  is  marked  as  an  error.  This  implementation  does 
not  additionally  flag  the  errors  in  the  bodies  and  thus  the  expected  error  at 
line  122  is  not  flagged.  The  AVO  ruled  that  the  implementation's  behavior  was 
acceptable  and  that  the  test  need  not  be  split  (such  a  split  would  simply 
duplicate  the  case  in  B83E01A  at  line  15). 

CA2009A,  CA2009C..D  (2  tests),  CA2009F  and  BC3009C  were  graded  inapplicable  by 
Evaluation  Modification  as  directed  by  the  AVO.  These  tests  contain 
instantiations  of  a  generic  unit  prior  to  the  compilation  of  that  unit's  body; 
as  allowed  by  AI -00408  and  AI-00506,  the  compilation  of  the  generic  unit  bodies 
makes  the  compilation  unit  that  contains  the  instantiations  obsolete. 

BC3204C  and  BC3205D  were  graded  passed  by  Processing  Modification  as  directed 
by  the  AVO.  These  tests  check  that  instantiations  of  generic  units  with 
unconstrained  types  as  generic  actual  parameters  are  illegal  if  the  generic 
bodies  contain  uses  of  the  types  that  require  a  constraint.  However,  the 
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generic  bodies  are  compiled  after  the  units  that  contain  the  instantiations, 
and  this  implementation  creates  a  dependence  of  the  instantiating  units  on  the 
generic  units  as  allowed  by  AI-00408  and  AI-00506  such  that  the  compilation  of 
the  generic  bodies  makes  the  instantiating  units  obsolete — no  errors  are 
detected.  The  processing  of  these  tests  was  modified  by  re-compiling  the 
obsolete  units;  all  intended  errors  were  then  detected  by  the  compiler: 

BC3204C:  CO,  Cl,  C2,  C3M,  C4,  C5,  C6,  C3M 

BC3205D:  DO,  DIM,  D2 ,  DIM 

BC3204D  and  BC3205C  were  graded  passed  by  Test  Modification  as  directed  by  the 
AVO.  These  tests  are  similar  to  BC3204C  and  BC3205D  above,  except  that  all 
compilation  units  are  contained  in  a  single  compilation.  For  these  two  tests,  a 
copy  of  the  main  procedure  (which  later  units  make  obsolete)  was  appended  to 
the  tests;  all  expected  errors  were  then  detected. 

CD2A53A  was  graded  inapplicable  by  Evaluation  Modification  as  directed  by  the 
AVO.  The  test  contains  a  specification  of  a  power-of-10  value  as  'SMALL  for  a 
fixed-point  type.  The  AVO  ruled  that,  under  ACVC  1.11,  support  of  decimal 
'SMALLs  may  be  omitted. 

AD9001B  and  AD9004A  were  graded  passed  by  Processing  Modification  as  directed 
by  the  AVO.  These  tests  check  that  various  subprograms  may  be  interfaced  to 
external  routines  (and  hence  have  no  Ada  bodies).  This  implementation  rec[uires 
that  a  file  specification  exists  for  the  foreign  subprogram  bodies.  The 
following  commands  were  issued  to  the  Librarian  to  inform  it  that  the  foreign 
bodies  will  be  supplied  at  link  time  (as  the  bodies  are  not  actually  needed  by 
the  programs,  these  commands  alone  are  sufficient: 

ALC40  interface/system  AD9001B 

ALC40  interface/system  AD9004A 

CE2103A,  CE2103B,  and  CE3107A  were  graded  inapplicable  by  Evaluation 
Modification  as  directed  by  the  AVO.  The  tests  abort  with  an  unhandled 
exception  when  USE_ERROR  is  raised  on  the  attempt  to  create  an  external  file. 
This  is  acceptable~behavior  because  this  implementation  does  not  support 
external  files  (cf.  AI-00332). 
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3 . 1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described  adequately 
by  the  information  given  in  the  initial  pages  of  this  report. 

For  technical  information  about  this  Ada  implementation,  contact: 

Mr  Ken  Butler 

Vice  President,  Product  Development 
Tartan  Inc. 

300,  Oxford  Drive 
Monroeville,  PA  15146  USA 
Tel.  (412)  856-3600 

For  sales  information  about  this  Ada  implementation,  contact: 

Ms  Marlyse  Bennet 
Tartan  Inc. 

12110  Sunset  Hills  Road 
Suite  450 

Reston,  VA  22090  USA. 

Tel.  (703)  715-3044 

Testing  of  this  Ada  implementation  was  conducted  at  the  customer's  site  by  a 
validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test  of 
the  customized  test  suite  in  accordance  with  the  Ada  Programming  Language 
Standard,  whether  the  test  is  applicable  or  inapplicable;  otherwise,  the  Ada 
Implementation  fails  the  ACVC  [Pro92]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained 
that  conforms  to  the  Ada  Programming  Language  Standard. 
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The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories. 
All  tests  were  processed,  except  those  that  were  withdrawn  because  of  test 
errors  (item  b;  see  section  2.1),  those  that  require  a  floating-point  precision 
that  exceeds  the  implementation's  maximum  precision  (item  e;  see  section  2.2), 
and  those  that  depend  on  the  support  of  a  file  system  —  if  none  is  supported 
(item  d).  All  tests  passed,  except  those  that  are  listed  in  sections  2.1  and 
2.2  (counted  in  items  b  and  f,  below). 


a)  Total  Number  of  Applicadsle  Tests  3440 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  86 

d)  Non-Processed  I/O  Tests  285 

e)  Non-Processed  Floating-Point 

Precision  Tests  264 


f)  Total  Number  of  Inapplicable  Tests  635  (c+d-^B) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a-*-b-«-f) 


3.3  TEST  EXECUTION 

A  TK50  cartridge  containing  the  customized  test  suite  (see  section  1.3)  was 
taken  on-site  by  the  validation  team  for  processing.  The  contents  of  the  TK50 
cartridge  were  loaded  directly  onto  the  host  computer. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of  tests 
was  processed  by  the  Ada  implementation. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as  appropriate. 
The  executable  images  were  transferred  to  the  target  computer  system  by  the 
communications  link,  an  RS232 ' Interface,  and  run.  The  results  were  captured  on 
the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  teeun.  See  Appendix  B  for  a  complete  listing  of  the 
processing  options  for  this  implementation.  It  also  indicates  the  default 
options.  The  options  invoked  explicitly  for  validation  testing  during  this  test 
were: 

Options  used  for  compiling: 

/C40  Invoke  the  C40-targeted  cross  compiler.  This  qualifier 

is  mandatory  to  invoke  the  C40-targeted  compiler. 

/REPLACE  Forces  the  compiler  to  accept  an  attempt  to  compile  a 

unit  imported  from  another  library  which  is  normally 
prohibited. 

/NOSAVE_SOURCE  Suppresses  the  creation  of  a  registered  copy  of  the 

~  source  code  in  the  library  directory  for  use  by  the 

REMAKE  and  MAKE  subcommands  to  ALC40. 

No  explicit  linker  options  were  used. 

Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on  a  TK50 
cartridge  and  archived  at  the  AVF.  The  listings  examined  on-site  by  the 
validation  team  were  also  archived. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC.  The 
meaning  and  purpose  of  these  parameters  are  explained  in  [UG89].  The  parameter 
values  are  presented  in  two  tables.  The  first  table  lists  the  values  that  are 
defined  in  terms  of  the  maximum  input-line  length,  which  is  the  value  for 
$MAX_ZN_LEN — also  listed  here.  These  values  are  expressed  here  as  Ada  string 
aggregates,  where  "V"  represents  the  maximum  input-line  length. 

Macro  Parameter  Macro  Value 


$MAX_IN_LEN  240  —  Value  of  V 

$B1G_^ID1  (1..V-1  «>  'A',  V  «>  '1') 

$B1G_ID2  (1..V-1  ■>  'A',  V  ■>  '2') 

$B1G  ID3  (1..V/2  ■>  'A')  .&  '3'  & 

(1..V-1-V/2  «>  'A') 

$BIG  ID4  (1..V/2  ->  'A')  &  '4'  & 

(1..V-1-V/2  «>  'A') 

$BIG_INT_LIT  (1..V-3  ->  '0')  &  "298" 

$BIG_REAL_LIT  (1..V-5  ■>  '0')  &  "690.0" 

SBIG_STRING1  S  (1..V/2  »>  'A')  6 

$BIG_STRING2  &  (1..V-1-V/2  ■>  'A')  &  '1'  6 

$BLANKS  (1..V-20  ) 

$MAX  LEN  INT  BASED  LITERAL 

"2:"  6  (1..V-5  ->  '0')  &  "11:" 

$MAX  LEN  REAL  BASED_LITERAL 

-16:"  6  (1..V-7  ->  '0')  &  "F.E:" 

$MAX  STRING  LITERAL  &  (1..V-2  ■>  'A')  & 


The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 
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Macro  Parameter 

Macro  Value 

SACC_SIZE 

32 

$AI.IGNMENT 

1 

SCOUNT_LAST 

2147483646 

SDEFA0LT_MEM_S1ZE 

16#FFFFFFFF# 

SDEFAOLT_STOR_UNIT 

32 

SDEFAULT_SYS_NAME 

TI320C40 

$DELTA_DOC 

2#1.0#E-31 

$ENTRY_ADDRESS 

SYSTEM. ADDRESS '( 16#2FF803#) 

$ENTRY_A0DRESS1 

SYSTEM.ADDRESS' (16#2FF804#) 

$ENTRY_A00RESS2 

SYSTEM. ADDRESS' (16#2FF805#) 

SFIELD_LAST 

240 

$F1LE_TERM1NAT0R 

0  0 

$FIXED_NAME 

NO__SUCH_TYPE 

$FLOAT_NAME 

MO_SDCH_TYPE 

SFORM^STRING 

fl  •• 

SFORM_STRlNG2 

■ CANNOT_RESTRlCT_FILE_CAPACITY " 

SGREATER  THAN  DURATION 

100^000.0 

$GREATER  THAN  DURATION  BASE  LAST 

T31_073.0 

$GR£ATER  THAN  FLOAT  BASE  LAST 

~  ~  "  3.f0282E+38 

SGREATER_THAN_FLOAT_ 

SAFE  LARGE 

1 . ^E+38 

$GREATER  THAN  SHORT  FLOAT  SAFE  LARGE 
“  “  ”  l.OE+38 

$HIGH__PRIORITY 

100  1 

SILLEGAL  EXTERNAL  FILE  NAMEl 

Tllegal_external_file_namei 

$ILLEGAL  EXTERNAL  FILE  NAME2 

~  ~  Illegal  external  file  name2 

S INAPPROPRIATE  LINE  LENGTH 

-1 

$  INAPPROPRI  ATE_PAGE, 

LENGTH 
■  -1 

$ INCLU0E_PRAGMA1 

PRAGMA  INCLUDE  ("A28006D1.TST" ) 

A-2 
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$  ZNCLU0E_PRAGMA2 

SINTEGER_FIRST 

$INTEGER_LAST 

S INTEGER_LAST_PLOS_l 

$INTERFACE_LANGUAGE 

$LESS_THAN_DURATZON 

$LESS  THAN  DURATION 


PRAGMA  INCLUDE 

-2147483648 

2147483647 

2147483648 

TI_C 

-100_000.0 

BASE  FIRST 
-ill  073.0 


("B28006F1.TST") 


$LINE_TERMINATOR  '  ' 

SLOW_PRIORITY  10 

$MACH I NE_CODE_STATEMENT 

"  Two^Opnds' (LDI,  (Inim,5) ,  (Rag,R0) ) ; 


SMACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

SM1N_INT 

$NAME 

$NAME_LIST 

$NAME_SPECIFICATI0N1 

$NAME_SPECIFICATION2 

$NAME_SPECIFICATION3 

SNEG_BASED_INT 

SNEW_MEM_SIZE 

SNEW_STOR__UNIT 

$NEW_SyS_NAME 

$PAGE_TERMINATOR 

SRECORD  DEFINITION 


Instruct ion_Mnamonic 

31 
9 

2147483647 

2147483648 

-2147483648 

NO_SUCH_TYPE_AVAlLABLE 

TI320C40 

D0A2: (ACVC11.C30.TESTBEDJX2120A. ;1 
D0A2: (ACVC11.C30.TESTBED]X2120B. ;1 
DUA2 : ( ACVCl 1 . C3 0 . TESTBED ] X3 1 1 9 A . ; 1 
16#FFFFFFFE# 

16#FFFFFFFF# 

32 

TI320C40 


rscord  Operation:  Instruct ion_Mneinonic; 
Oparand_l:  Operand;  Operand_2T  Operand; 
and  record; 


$RECORO_NAME 
$TASK_SIZE 
$TASK_STORAGE_SI ZE 
STICK 


Two^Opnds 

32 

4096 

0.00006103515625 
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$VARIABLE_ADORESS  SYSTEM. ADDRESS '( 16#2FF800#) 
$VARIABLE_ADDRESS1  SYSTEM. ADDRESS ' ( 16#2FF801#) 
$VARIABLE_AOORESS2  SYSTEM. ADDRESS ' ( 16#2FF802#) 
SYOUR  PRAGMA  NO  SUCH  PRAGMA 
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COMPILATION  SYSTEM  OPTIONS 


Th«  compilar  options  of  this  Ada  implementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise,  references 
in  this  appendix  are  to  compiler  documentation  and  not  to  this  report. 
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Chapter  4 

Compiling  Ada  Programs 


Tbe  TAOA/  C  4  0  is  used  to  compile  and  assemble  Ada  compiladon  units. 

4.1.  THE  TADA/C40  COMMAND 

Fonnat:  The  TAOA/C40  command  has  this  fonnac 
S  TADA/C40  Vqucdifieri  {option,  . .  . ) _ ]  ]  fiU-spec [/qualifier  [  {option,  —  )...]] 

The  panuneter  file-spec  is  a  source  file  name.  Since  tbe  source  files  need  not  reside  in  the  directory  in  which 
the  compiladon  takes  place,  file-spec  must  inftiuHe  sufficient  directory  infbrmanon  to  locate  the  file.  If  no 
extenaioa  is  supplied  with  tbe  file  name,  a  default  extension  of  .ADA  will  be  supplied  by  the  compiler. 

The  source  file  may  more  than  one  compiladon  nntt,  but  it  is  considered  good  pracdce  to  place  only 

one  compiladon  unit  in  a  file. 

Output:  The  compiler  sequentially  processes  all  compiladon  units  in  the  file.  Upon  successful  compiladon 
ofaunic 

•  The  Ada  program  library,  LIBRARY .  DB.  is  updated  to  refiea  the  new  compiladtm  time  and  any  new 
dependencies. 

•  One  or  more  separate  compiladon  files  and/or  objea  files  are  generated. 

If  no  errors  are  detected  in  a  compiladon  unit,  the  cmnpiler  produces  an  object  module  and  updates  the 
library.  If  any  error  is  detected,  no  objea  code  file  is  produced,  a  source  listing  is  produced,  and  no  library  entry 
is  for  that  pmmpiUti^  nnit  If  warnings  are  generated,  both  an  objea  code  file  and  a  source  listing  are 
produced,  and  the  libnry  is  updated. 

Refinements:  The  compiler  is  capable  of  limidng  tbe  nmwher  of  library  units  that  become  obsolete  in  the 
following  manner.  A  libnry  unit  is  a  refinement  of  its  previously  compiled  version  if  the  only  charges  that  were 
made  are: 

•  Adding  or  deleting  of  comments 

•  Adding  subprogram  specificstioos  after  tbe  i*-**  declarative  item  in  tbe  previous  versioo 

A  qnslificr  is  required  to  the  y"ptlw  to  detea  lefinemems.  When  a  refinement  is  detected  by  tbe 
compiier,  dependent  units  ate  not  marked  as  obsolete.  If  a  unit  is  a  refinement  of  its  previous  compilaoon.  no 
other  unit  on  it  becomes  obsolete  because  of  this  teconqnlsiioo.  The  excepdon  to  this  rule  is.  the  body 

of  the  specification  is  still  obsolete  for  dm  esse  where  a  new  dedaratitm  was  added. 
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4.2.  COMMAND  QUAUFIERS 

Command  qualifiers  indicate  special  actions  to  be  pertonned  by  the  compiler  or  special  ouq>ut  file  properties. 
A  qualifier  identifying  the  target-code  format  must  be  used  to  invoke  the  C40-target^  compiler.  The  following 
qualifiers  are  available: 

/ C40  Invoke  the  C40-targeted  cross  compiler.  This  qualifier  is  mandatory  to 

invoke  the  C40-targeted  compiler. 

/  CALLS-opno/i  Allows  the  user  to  specify  the  size  of  the  address  space  into  which  the 

linked  applicatioa  co^  will  fit  The  compiler  will  generate  code,  based 
on  the  user’s  assertiaa.  The  available  options  are: 

LONG  The  user  asserts  that  the  linked  applicatioa  code  will  not 

fit  within  a  23-bit  (2^  •  1)  address  space. 

SHORT  The  user  asserts  that  the  linked  application  code  will  fit 

within  a  IS-bit  (2^^  - 1)  address  space. 

If  the  /CALLS-SHORT  aaseitico  is  incotrecL  the  linker  will  produce 
error  messages  at  link-time.  If  the  /CALLS -LONG  switch  is  given  and 
the  code  fits  within  a  23-bit  (2^  -  1)  space,  no  etror  is  given  by  the 
linker,  because  the  code  is  sdll  correcc  however,  it  is  less  efficiem.  By 
defuilL  the  compiler  will  generate  code  «-<!oiniing  that  the  linked  applica- 
don  code  fits  within  a  23-bit  (2^  - 1)  address  space. 


/CROSS_REFERENCE 
/NOCROSS_REFERENCE  [Default] 

Controls  whether  the  compiler  generates  cross-reference  informadoo  in 
the  objea  code  file  to  be  u^  by  the  TXREF  tool  (see  Secdon  4.5).  This 
qualifier  may  be  used  only  with  the  Tartan  Tool  Set 


/DATA_PAGE_IS_ROM  Limit  data-page  references  to  compile-  and  link-time  canstants.  Sttd- 

~  cally  ailocaited  variaUes  nonnally  accessed  using  dau  page  addressing 

will  be  reached  via  laag”  tefetences.  This  opdon  must  be  used  on  all 
compUadon  units  of  an  applicadoo  if  it  is  used  on  any  one. 


/DEBUG 

/NODEBUG  [Defiult]  Controls  whether  debuggmg  infoonadoo  is  included  in  die  object  code 

file.  It  is  not  necesaary  for  all  object  modules  to  include  debugging 
mfonnadon  to  obtain  a  linkable  image,  but  use  of  diis  qualifier  is  en¬ 
couraged  for  all  compiladons.  No  significani  execndoo-dme  penalty  is 
incurred  with  this  qualifier. 


/DELAYED_BRANCHES  [Defnilt] 

/NODELAYED_BRANCHES  Controls  whether  the  compiler  generates  delayed  branch  insttuedons 

(detailed  in  Secdon  1 1.4). 


/ENUMERATION_IMAGES  [Defindt] 

/ NOENUMERATION_IMAGES  Causes  the  compiler  to  omk  data  segmens  with  the  text  of  enumeradon 

literals.  This  text  is  nonnally  produced  for  exported  enumeradon  types  in 
order  to  support  the  text  attributes  ('  IMAGE.  'VALUE  and  'WIDTH). 
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/ERROR  LIMIT=« 


/FIXUPl-opwon] 


/HUGE  LOOPS  [Default] 
/NOHUGE  LOOPS 


/  LIBRARY^/idreoy-name 


/LIST(-opfion] 

/NOLIST 


You  should  use  /MCEN'UMER.-.riON_iyiAGZ3  only  when  you  can 
guarantee  that  no  unit  that  will  impon  the  enumeration  type  will  use  any 
of  its  text  attributes.  However,  if  you  are  compiling  a  unit  with  an 
enumeration  type  that  is  not  visible  to  other  compilation  units,  this 
qualifier  is  not  needed.  The  compiler  can  recognize  when  the  text  at¬ 
tributes  are  not  used  and  will  not  generate  the  supporting  strings. 


Stops  compilation  and  produces  a  listing  after  n  errors  are  encountered, 
wbm  /I  is  in  the  range  0  ..  25S.  The  default  value  for  n  is  2SS.  The 
/£RROR_LIMIT  qualifier  cannot  be  negated. 


When  package  .Machine_Code  is  used,  controls  whether  the  compiler 
attempts  to  alter  operand  address  modes  when  those  address  modes  ate 
used  incorrectly,  liie  available  options  ate: 

QUIET  The  compiler  attempts  to  generate  extra  instructians  to 

fix  inconeci  address  modes  in  the  array  aggregates 
operand  field. 

WARN  The  compiler  attempts  to  generate  exna  insouctions  to 

fix  inconrect  address  modes.  A  warning  message  is 
issued  if  such  a  conecdcn  is  required. 

NONE  The  compiler  does  not  attempt  to  fix  any  machine  code 

insertion  that  has  incorrect  address  modes.  An  error 
message  is  issued  for  any  maghinii  code  insertimi  that  is 
incorrect. 

When  no  form  of  this  qualifier  is  supplied  in  the  command  line,  the 
default  condition  is  /FIXUP-QUIET.  For  more  informatioa  on  maehine 
code  insertions,  refer  to  Section  5.10  of  this  manual. 


When  the  NCHUGE_LOOPS  qualifier  is  specified,  the  user  is  asserting 
that  no  loops  will  iterate  more  than  2^  times.  This  limit  includes  non- 
user  specific  loops,  such  as  those  loops  generated  by  the  compiler  to 
operate  on  large  objects.  Erroneous  code  will  be  generated  if  this  asser¬ 
tion  is  false. 


Specifies  the  library  into  which  the  file  is  to  be  compiled.  The  compiler 
still  reads  any  ADALI5 .  INI  files  in  the  default  directory  and  will  report 
any  associated  error,  but  this  qualifier  will  override  the  AOAL  IB.  INI. 


Cotmols  whether  a  listing  file  is  produced.  If  produced,  the  file  has  die 
source  file  name  and  a  .LIS  extension.  The  arable  options  are: 

ALWAYS  Always  produce  a  listing  file 

NEVER  Never  produce  a  listing  file,  equivalem  to /NOLIST 

ERROR  Produce  a  listing  fite  only  if  a  compilatioo  error  or  warn¬ 

ing  occurs 


COMPILATION  SYSTEM  MANU.\L 


When  no  form  of  this  qualifier  is  supplied  in  the  command  line,  the 
default  condition  is  /  1I3T«ZRRCR.  When  the  LIST  qualifier  is  sup¬ 
plied  without  an  option,  the  default  option  is  ALWAYS. 


/  MACHIWE_CCDE[»opnon]  Controls  whether  the  compiler  produces  an  assembly  code  file  in  addition 

to  an  object  file,  which  is  always  generated.  The  assembly  code  file  is 
not  intended  to  be  input  to  an  assembler,  but  serves  as  documentatioa 
only.  The  available  options  are: 

NONE  Do  not  produce  an  assembly  code  file. 

INTERLEAVE  Produce  an  assembly  code  file  which  interleaves 
source  code  with  the  machine  code.  Ada  source 
appears  as  assembly  language  comments. 

NO  INTERLEAVE  Produce  an  assembly  code  file  without  interleaving. 

When  no  fonn  of  this  qualifier  is  supplied  in  the  command  line,  the 
default  option  is  NONE.  Specifying  the  /MAC.4INE_CCD£  qualifier 
without  an  option  is  equivalent  to  supplying 

/MAC.HINE_CODE-NOINTERLEAVE. 

/MAX_RPTS_CCLNT»/i  Controls  the  maximum  iteration  count  for  a  loop  using  the  RFTS  instruc¬ 

tion.  where  n  is  an  integer  in  the  range -1  ..2^*  -1.  Since  an  RfTS  loop  is 
noQ-intetruptibie.  this  qualifier  allows  control  over  the  interrupt  latency 
time.  The  default  value  is  32.  A  value  of  minus  oat  (-1)  specifies  no 
limiL  A  value  of  zero  (0)  specifies  than  that  no  RFTS  instractioas  will  be 
generated.  Any  positive  value  sets  the  maximum  iteration  couru.  If  a 
value  in  the  range  0  ..  31  is  used,  it  will  be  necessary  to  customize  the 
lunfimes.  Please  contact  Tartan  for  informadoo  on  bow  to  perform  these 
customizadons. 

CPTIMIZEsophon  Controls  the  level  of  opdmizauon  perfonned  by  the  compiler  according 

to  the  following  opdons:  MINIMUM,  LOW,  STANDARD,  TIME,  and 
SPACE.  The  resold  of  the  opdons  are: 

Petfonns  context  detetmiiudon.  constant  folding,  al¬ 
gebraic  manipuladan.  and  short  drcuit  analysis.  Inlines 
are  not  expanded. 

Performs  MINIMUM  opdmizadons  plus  common  sub¬ 
expression  eliminadon  and  equivalence  propagadon 
within  basic  Mocks.  It  also  optimizes  evaluadon  order. 
Inlines  ate  not  expanded.  AdaScope  performs  best  when 
compiled  at  this  level. 

(Best  tradeoff  for  spaoe/dme)  -  defcadt  option.  Performs 
LOW  opdmizatioos  pins  flow  analysis  adiich  is  used  for 
enmnion  subexpression  eliminadon  and  equivalence 
propagadon  across  basic  Mocks.  It  also  performs  in- 
vaiiam  expression  hoisdi^  dead  code  eliminadon.  and 
ijwwwit  killing.  With  STANDARD  opdmizadoa 
lifedine  analysis  is  performed  to  inqueve  register  alloca- 
don  and  if  possiMe.  inline  expansion  of  subprogram  calls 
indicated  by  pragma  INLINE  are  performed. 
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MINIMUM 


LOW 


STANDARD 
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TIME  Performs  STA'IDA-RE  optimizations  plus  inline  expan¬ 

sion  of  subprogram  calls  which  the  optimizer  decides  are 
profitable  to  expand  (from  an  execution  tune  perspec¬ 
tive).  Other  optimizations  which  improve  execution  time 
at  a  cost  to  image  size  are  performed  only  at  this  level. 

SP.^CE  Performs  those  opdmizatioos  which  usually  produce  the 

smallest  code,  often  at  the  expense  of  speed.  Please  note 
that  this  optimizatian  level  may  not  always  produce  the 
snudlest  code.  Under  certain  conditions,  another  level 
may  produce  smaller  code. 


/PARSE 

.  NCP  ARS  E  Extracts  syntactically  conect  compilation  unit  source  from  the  parsed  file 

and  loads  this  file  into  the  library  as  a  parsed  unit.  Parsed  units  are.  by 
definidon.  inconsistem.  This  switch  allows  users  to  load  units  into  the 
library  without  regard  to  correa  compilauon  order.  The  command 
REMAKE  is  subsequently  to  reorder  the  compiladon  units  in  the 
conect  sequence.  See  Secdon  13.2.4.3  for  a  more  complete  descripdon 
of  this  command. 


Controls  whether  the  compiler  announces  each  phase  of  processing  as  it 
occurs.  These  phases  indicate  progress  of  the  compiladon.  If  there  is  an 
error  in  compiladon.  the  error  message  will  direa  users  to  a  specific 
locadon. 


Controls  whether  the  compiler,  when  cmnpiling  a  library  unit,  determines 
whether  the  unit  is  a  refinement  of  its  previous  version  and.  if  so.  does 
not  make  dependent  units  obsolete.  The  default  is  /  NOREF I NE . 

/  REMAKE  Daxa  on  this  switch  is  provided  for  information  only.  This  switch  is  used 

exclusively  by  the  Tartan  Ada  Librarian  to  notify  the  compiler  that  the 
source  undergoing  campiladon  is  an  internal  source  file.  The  switch 
causes  the  compiler  to  retain  old  external  source  file  informadon.  This 
switch  should  be  used  only  by  the  librarian  and  comtnaod  files  created  by 
the  librarian.  See  Secdon  3.6.1. 


/REPLACE 

/ NOREPLACE  Pefsult]  Forces  the  compiler  to  accept  an  attempt  to  compile  a  unit  imported  from 

another  library  which  is  nminally  prohibited. 

/  REVan  Revision  of  the  C40  silicon,  where  n  is  an  integer  in  the  range  1  ..  2.  The 

default  value  fore  is  2. 


/REFINE 

/NOREFINE  (Default) 


/PHASES 

/NOPHASES  [Default] 


/SAVE  SOURCE  (Default) 
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/  3UPPRESS[”<op«o/j,  ..J] 


/SYNTAX_ONLY 
/NOSYNTAX  ONLY  DDefault] 


/WARNINGS  [Default] 
/NOWARNINGS 


Suppresses  the  creation  of  a  registered  copy  of  the  source  code  in  the 
library  directory  for  use  by  the  REMAKE  and  MAKE  subcommands  to 


ALC40. 


Suppresses  the  specific  checks  identified  by  the  options  supplied.  The 
parentheses  may  be  omitted  if  only  one  option  is  supplied.  Evoking  this 
option  will  not  remove  all  checks  if  the  resulting  code  without  checics 
will  be  less  efficienu  The  /SUPPRESS  qualifier  has  the  same  effect  as  a 
global  pragma  SUPPRESS  applied  to  the  source  file.  If  the  source 
program  also  contains  a  pragma  SUPPRESS,  a  given  check  is  suppressed 
if  ei±er  the  pragma  or  the  qualifier  specifies  it:  that  is.  the  effect  of  a 
pragma  SUPPRESS  cannot  be  negated  with  the  command  line  qualifier. 
The  /SUPPRESS  qualifier  cannot  be  negated. 

The  available  options  are: 

ALL  Suppress  all  checks.  This  option  is  the 

default  when  no  option  is  supplied. 

.^CCESS_CHECK  As  specified  in  the  Ada  LRM.  Section  1 1.7. 

CONSTRAINT_CHECK  Equivalent  of  all  the  following: 

ACCESS^  '""ECK.  INDEX_CHECK, 

DISCRIMINANT_CHECK. 
LENGTH_CHECK.  RANGE_C.HECK. 

DISCRIMINANX_CHECK  As  specified  in  the  Ada  LRM,  Section.11.7. 

DIVIS  ION_CHECK  Will  suppress  compile-time  checks  for  divi¬ 
sion  by  zero,  but  the  hardware  does  not  per¬ 
mit  efficient  runtime  checks,  so  none  are 
done. 


ELABORAT ION_CHECK 
INDEX_CHECK 
LENGTH_CHECK 
OVERFLOW  CHECK 


RANGE_CHECK 
STORAGE  CHECK 


As  specified  in  the  Ada  LRM,  Section  1 1.7. 
As  specified  in  the  Ada  LRM.  Section  1 1.7. 
As  specified  in  the  Ada  LRM,  Section  1 1.7. 

Vfill  suppress  compile-dme  checks  fm  over¬ 
flow,  but  the  hardware  does  not  permit  ef- 
fldetu  mndme  checks,  so  none  are  done. 

As  specified  in  the  Ada  LRM,  Secdon  1 1.7. 

As  specified  in  the  Ada  LRM.  Section  11.7. 
Suppresses  only  stack  checks  in  generated 
co^,  not  the  checks  made  by  the  allocator  as 
a  result  of  a  new  (q)eration. 


Examines  units  for  syntax  errors,  then  stops  compilation  without  entering 
a  unit  in  the  library. 


Controls  whether  the  warning  messages  generated  by  the  compiler  are 
displayed  to  the  user  at  the  terminal  and  in  a  listing  file,  if  produced. 
While  suppressing  warning  messages  also  halts  display  of  informational 
messages,  it  does  not  suppress  Error.  Facal_Error. 
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S»n 

S  ^option  :n  [  /  option  :n  .  .  .  ] 

The  wait  states  conunaod  lin*  qualifier  accepts  either  a  single  numeric 
digit  or  a  list  of  one  or  more  options. 

A  single  numeric  digit  specifies  the  number  of  wait  states  to  use  for 
program  code,  data  page.  heap,  and  stack,  where  /i  is  an  integer  in  the 
range  0  7-  The  default  value  for  n  is  2  or  the  maximum  wait  state  of 
program  code,  dau  page.  heap,  or  suck. 

The  following  options  may  be  specified: 

CODEtn  Specifies  the  number  of  wait  states  for  the  block  of 
memory  in  which  program  code  will  be  executed,  where 
/I  is  an  integer  in  the  range  0  ..  7.  The  default  value  for  n 
is  2. 

OAT.A.:/!  Specifies  the  number  of  wait  states  for  the  block  of 
memory  where  the  dau  page  for  the  current  compilation 
unit  resides,  where  n  is  an  integer  in  the  range  0 ..  7.  The 
default  value  for  n  is  2. 

HEAP:/!  Specifies  the  number  of  wait  sutes  for  the  block  of 
memory  where  the  heap  resides,  where  />  is  an  integer  in 
the  range  0 ..  7.  The  defiiult  value  for  n  is  2. 

STACK  :n  Specifies  the  number  of  wait  states  for  the  block  of 
nremory  where  the  stack  resides,  where  n  is  an  integer  in 
the  range  0 ..  7.  The  default  value  for  n  is  2. 

Examples: 

TADA/C40/WAIT  STATES-4 
TADA/C40/WAIT”STATES- (CODE : 4 ,  DATA: 2) 
TADA/C40/WAIT-  (C:  1 ,  D : 2 ,  .4 : 3,  S :  4 ) 
TADA/C40/WAIT_STATES-  (HEAP-1,  STAC.K-7) 
TADA/C40/WAIT_STATES : 2 
TADA/C40/WAIT : CODE : 1 

Note  that  sod  are  interchangeable.  A  keyword  can  be 
specified  by  using  only  enough  characters  to  make  it  unique.  When  more 
than  one  option  is  specified,  the  list  of  options  must  be  enclosed  in 
parentheses. 
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The  linker  options  of  this  Ada  implementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise,  references 
in  this  appendix  are  to  linker  documentation  and  not  to  this  report. 
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2  J,  INVOKING  THE  UNKER 

The  linker  may  be  invoked  either  through  the  Ada  librarian,  or  direcdy  by  the  user.  Invocation  through  the 
librarian  ensures  that  all  Ada  language  consistency  and  dependency  requirements  are  meL  Use  of  the  librarian  is 
the  most  common  way  of  liniring  ao  Ada  program.  Direct  invocation  of  the  linker  is  used  mostly  for  link 
operatioas  that  are  outside  the  boundaries  of  an  Ada  program.  Examples  of  the  latter  are  construction  of 
assembly  language  boot  images,  combining  multiple  Ada  programs  into  a  single  image,  or  creating  patches  for  an 
existing  program. 

22.1.  Using  the  Tartan  Librarian  to  Invoke  the  Linker 

Normally,  Ada  programs  are  linked  using  the  Ada  librarian.  The  command  for  linking  through  the  librarian  is 
$  ALC40  LINK  [Iqualifier...]  mainjmit 

The  parameter  mainjuut  must  be  supplied.  It  sped&es  the  unit  in  the  library  to  be  made  the  main  program. 

The  use  of  the  Ada  librarian  to  link  a  program  is  described  in  the  Compilation  System  Manual. 

Quptera  3  and  9.  Here  we  will  describe  the  interface  between  the  librarian  and  the  linker,  and  the  manner  in 
whi^  the  necessary  information  is  passed. 

The  Ada  librarian’s  LINK  subcommand  that  the  unit  within  the  library  specified  by  die  user  has  the 
legal  fonn  for  a  mat"  unit,  all  its  dependencies,  all  required  object  fil^  and  invokm  the  tinker.  The 
librarian  creates  two  files  that  ate  used  as  input  to  the  link  process.  These  files  are  listed  by  name  below;  the 
name  mainjmit  refers  to  the  name  of  the  main  program  unit 

mainjmit. CTL  This  file  contains  the  list  of  objea  files  that  are  to  be  included  in  the  link.  Thefile 

is  written  as  a  list  of  linker  WITH  commands,  each  specifying  a  file  to  be  included. 

mainjmit.et.of  This  object  file  contains  a  procedure  to  perform  elaboration  of  the  Ada  program. 

The  code  in  this  file  is  in  the  executable  and  will  ultimately  be  invoked 

by  die  Ada  runtimes  when  the  program  is  executed. 

These  files  ate  normally  deleted  by  the  Ada  librarian  at  the  completion  of  the  link  step.  They  may  be  retained 
by  use  of  the  qualifier  /KEEP,  described  in  the  Compilation  System  Manual,  Section  13.S.10.  If  no  changes  ate 
iriaria  to  the  ptogiim  that  would  invalidate  the  dependency  and  closure  information  contained  in  these  files, 
subsequent  li^  may  be  performed  by  invoking  the  linker  directly. 

After  writing  the  necessary  files,  the  Ada  librarian  invokes  the  linker.  The  invocation  performed  is  equivalent 
u>  the  following  user-level  ooinmanri; 

$  TLINKC40  /CONTROL-/r/iter_cwitro/ Jile  /OUTPUT-mawi_urtif.XTOF 

In  this  example,  linker  j:ontr<d  Jile  is  the  name  of  a  file  containing  linker  control  commands.  This  control  file 
describes  the  details  of  how  the  program  image  is  to  be  constructed  for  the  particular  target  system.  The  user 
may  specify  to  the  Ada  librarian  which  linker  control  file  to  uae.  If  no  file  is  specified,  the  librarian  uses  a  defuilt 
control  file  located  in  the  TAOAHOME  directory  and  »■"<*«<  TLINKC40 .  LCF.  Note  that  the  default  control  file 
expects  the  qualifier  /OUTPUT*  to  be  specified  in  the  line.  It  also  expects  the  file  mainjmit .  CTL  to 

exist. 

222.  Direct  Invocation  of  the  Linker 

The  linker  is  controlled  by  ermrmmtui  qualifiers  and  by  commands  in  a  linker  control  file.  Command 
qualifiers  are  used  to  specify  things  that  vary  according  » the  particular  link  bong  performed.  Examples  are  the 
name  of  the  output  file,  whether  or  not  to  produce  a  link  map.  and  adiedier  to  eUminiue  unused  code.  The  control 
file  is  used  to  specify  in  general  how  to  build  a  program  for  the  particular  target  system  and  hardware.  The 
command  qualifiers  may  vary  with  each  link,  but  the  control  file  is  usually  fixed  for  the  system  at  hand. 

The  general  format  at  the  invocation  of  the  linker  is 

$  TLINKC40  /CONTROL-linter_co«rol Jile  [Iqual^er...]  filespec... 


SlOl 
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Some  command  qualifiers  specify  particular  file  names  (fw  example,  the  name  of  the  linker  control  file). 
Other  file  names  may  also  appear  in  the  command  line:  these  nama«  are  interpreted  as  the  names  of  object  files  to 
be  included  as  input  to  the  link  process.  Input  files  may  also  be  specified  within  the  linker  control  file. 

When  the  linker  is  invoked  directly,  the  qualifier  /CONTROL-/iiutrr_comro/  Jile  must  be  supplied  in  the 
command  line.  (When  invoked  by  ALC 4  0,  it  is  the  lifarariaiL  not  the  linker,  that  supplies  a  default  linker  comrol 
file.)  This  command  qualifier  directs  the  linker  to  the  cmuroi  file  that  specifies  how  to  perfoim  the  link.  Only 
one  such  file  nuy  be  specified.  A  user  who  does  not  have  a  special  control  file  may  use  the  default  file  used 
the  Ada  libnrian.  Refer  to  the  previous  section  for  a  description  of  the  link  process  used  by  the  Ada  librarian. 

The  additional  arguments  to  the  linker  depend  upon  the  convention  used  by  the  control  file  you  specify.  For 
example,  input  object  files  may  be  qredfied  on  the  line,  in  the  control  file,  or  in  anoc^  li^r  control 

file.  Specification  on  the  command  line  is  convenient  if  a  number  is  involved.  For  larger  numbers  of  input 
files,  tte  WITH  command  (Section  2.6.5)  may  be  used  inside  the  linker  control  file,  or  in  another  linker  control 
file  included  with  the  CONTROL  file  command. 

If  your  control  file  uses  the  same  conveniiao  as  the  default  one.  the  «»tnnanri  Uae  will  look  like: 

S  TLINKC40  /CONTROLW//il»r_comrof Jile  /OUTPUT-oum/e.xcof 

The  control  file  would  then  expect  that  the  file  outfUe .  ctl  contains  the  list  of  input  file  WITH  commands.  A 
CONTROL  emtimnH  in  (jie  link^  contTOl  file  causes  this  additional  file  to  be  read.  A  derived  file  specification 
(see  Section  2.6.9)  is  used  in  the  CONTROL  command  to  allow  the  linker  to  infer  the  file  name  from  tte  specified 
output  file  name. 

The  convennon  used  by  the  default  control  file  is  only  one  way  in  which  arguments  could  be  specified.  Your 
own  linker  control  file  can  be  set  up  to  ejqrea  the  input  and  output  file  on  the  command  line,  or  to  derive  the 
output  filename  from  a  specified  input  file,  or  to  specify  both  in  the  control  file.  The  cooventi<n  used  in 
spe^'purpose  control  files  can  be  adjusted  to  fit  the  circumstances  at  hand.  Secdon  2J2  introduces  the  WITH, 
OUTPUT,  and  CONTROL  commands  that  are  used  to  set  up  customized  conventions. 

A  user  who  is  simply  relinking  a  progiim  will  need  u  know  only  a  couple  of  cnmmanri  qualifiers  and  the 
convention  esublished  by  the  system>specific  linker  control  file  used  for  the  system.  A  user  who  needs  to  alter 
the  program  layout  for  a  specific  target  system  will  require  the  wider  spectrum  of  commands  available  in  the 
linkiCT  control  ffle.  Gxnmand  qualifieis  are  described  in  the  next  section:  the  linker  control  file  commands  are 
described  in  Section  2fi. 
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23.  COMMAND  QUAUFIERS 

This  section  describes  the  comnisnd  qualifiers  available  to  a  user  wbo  directly  invokes  the  linker.  The 
qualifier  names  can  be  abbreviated  to  unique  prefixes;  the  first  letter  is  sufficient  for  all  cutiem  qualifier 
The  qualifier  names  ate  not  case  sensitive. 

/  CONTROL»/inJfcer_comro/ Jile 

The  specified  file  linker  cimirol  commands.  Only  one  such  file  may  be 

specified,  but  it  can  include  other  files  rising  the  CONTROL  command.  Every 
invocation  of  the  linker  must  spediy  a  control  file. 

/  OUTPUT>^/eruime  The  specified  file  is  the  name  of  the  first  output  object  file.  The  module  name  for 

this  file  will  be  null.  Only  one  output  file  may  be  specified  in  this  manner. 
Addidonal  output  files  may  be  specified  in  the  linker  control  file. 

/MAP  Produce  a  link  map  containing  all  infotmatioo  except  the  unused  section  listings. 

When  /MAP  is  specified  without  a  file  name,  the  name  of  the  file  conaining  the 
link  map  is  spedfied  by  the  LIST  in  the  linker  cootrol  file.  If  your 

control  file  does  not  specify  a  name  and  you  request  a  listing,  the  listing  will  be 
written  to  the  default  output  stream. 

/MAP ’“filename  Produce  a  link  map  coruaining  all  infonnation  except  the  unused  section  listings. 

The  map  is  written  to  the  spedfied  file. 

/ALLOCATIONS  'Produce  a  link  map  shouting  the  section  ailocatiaos. 

/UNUSED  Produce  a  link  map  ahosnng  the  unused  sections. 

/  SYMBOLS  Produce  a  link  map  showing  global  and  external  symbols. 

/  LOCALS  «j?lename  Causes  the  linker  to  retain  local  symbol  definitions  in  the  output  file  specified. 

/RESOLVEMODULES  This  qualifier  causes  the  linker  to  not  perform  unused  section  elimination. 

Specifying  this  option  will  generally  m^  your  program  larger,  since  un¬ 
referenced  dam  within  object  files  will  not  be  elimina^.  Refer  to  Sections  2.6J 
and  2.4J.2  for  infotmatioo  on  the  way  that  unused  section  elimination  works. 

Note  that  several  listing  options  ate  permitted  because  link  maps  for  real  systems  can  become  rather  large, 
axxl  writing  them  consumes  a  significant  fiaction  of  the  total  Nnk  time.  Options  specifying  the  contents  of  the 
link  map  can  be  combined,  in  which  case  the  resulting  map  will  contain  all  the  infonnation  specified  by  any  of 
the  switches. 


APPENDIX  C 

APPENDIX  F  OF  THE  Ada  STANDARD 


Th«  only  allowad  Implamantation  dapandancias  corraapond  to 

implamantation-dapandant  pragmas,  to  cartain  machine-dapandant  conventions  as 
mantionad  in  Chapter  13  of  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  inplamantation-dapandent 
characteristics  of  this  Ada  implementation,  as  described  in  this  Appendix,  are 
provided  by  the  customer.  Unless  specifically  noted  otherwise,  references  in 
this  Appendix  are  to  compiler  documentation  and  not  to  this  report. 
Implementation- specific  portions  of  the  package  STANDARD,  which  are  not  a  part 
of  Appendix  F,  are: 


package  STANDARD  is 


type  INTEGER  is  range  -2  147  483  648  ..  2  147  483  647; 

type  FLOAT  is  digits  6  range”-16?0. 1000_05#E+l3  .7  16#0.FFFF_FF#E+32; 

type  LONG  FLOAT  is  digits  9  range  -16#0. 1000_000  0#E't’33  .. 

lI#O.FFFF_PPFF  0#E+32; 

type  DURATION  is  delta  0.0001  range  -86400.0  ..  86400.0;  ~ 

—  DURATION 'SMALL  -  2#1.0#E-14  (that  is,  6.103516E-5  sec) 


end  STANDARD; 
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Chapter  5 

Appendix  F  to  MIL-STD-1815A 


This  chapter  cootaiiis  the  required  Appendix  P  to  the  LRM  which  is  Military  Standard,  Ada  Programming 
Language,  ANSI/MO^-STD-ISISA  (American  Natitmal  Standards  Instimte.  Inc.,  February  17. 1983) . 

S.L  PRAGMAS 

5.1.1.  Prtdefined  Pragmas 

This  secdon  summarizes  the  effects  of  and  resoictioiis  on  predeSned  pragmas. 

•  Access  coilecdoos  are  not  subjea  to  automatic  stonge  reclamadon  so  pragma  CONTROLLED  has  no  effect 
Space  deallocated  by  means  of  UNCHECKEO^DEALLOCATION  will  be  reused  by  the  allocation  of  new 
objects. 

•  Pragma  ELABO'RATE  is  supported. 

•  ftxgma  INLINE  is  supported. 

•  Pragma  INTERFACE  is  supported.  The  LANGUAGE_NAME  TI_C  is  used  to  make  calls  to  subprograms 
(written  in  the  Texas  Instruments  C  language)  from  Tartan  Ada.  Any  other  LANGUAGE_NAME  will  be 
accepted,  but  ignored,  and  the  default  language.  Ada.  will  be  used. 

•  Pragma  LIST  is  supported  but  has  the  intended  effect  only  if  the  command  qualifrer  /LIST-.\LWAYS  was 
supplied  for  compilatioa.  and  the  listing  generated  was  not  due  to  the  presence  of  errors  and/or  warnings. 

•  Pragma  MEMORY_S  I ZE  is  supported.  See  Section  5.13. 

•  Pragma  OPTIMIZE  is  supported  except  when  at  the  outer  level  (that  is,  in  a  package  spedficadon  or 
body). 

•  Pragma  PACK  is  supported. 

•  Pragma  PAGE  is  supported  but  has  the  intended  effea  only  if  the  command  qualifier  'LIST-ALWAYS  was 

supplied  for  and  the  listing  generated  wu  not  due  to  the  presence  of  errors  and/or  warnings. 

•  Pragma  PRIORITY  is  supported. 

•  Pragma  STORAGE^UNIT  is  acoqrted  but  no  value  other  than  that  specified  in  package  SYSTEM  (Secdon 
53)  is  allowed. 

•  Pragma  SHARED  is  mx  supported. 

•  Pragma  SUPPRESS  is  supported. 

•  Pragma  SYSTEM_NAME  is  accepted  but  no  value  other  than  that  specified  in  package  SYSTEM  (Secdon 
53)  is  allowed. 

S.1J.  ImpUmantation-Dtflnsd  Pragmas 

frnplementatioii-defiaed  pragmas  provided  by  Tartan  ate  described  in  the  following  secdoos. 
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5JJ.1.  Prisma  LI>JKAGE_NA:>iE 

Hie  pragma  LINKAGE_NAME  associates  an  Ada  entity  with  a  string  is  meaningful  externally;  for 
example,  to  a  linkage  editor.  It  takes  the  form 

pragma  LINKAGE_NAME  (Ada-simple-name.  string-constant) 

The  Ada-simple-name  must  be  the  name  of  an  Ada  entity  declared  in  a  package  specification.  This  entity  most  be 
one  that  has  a  runtime  leptesentadoo:  for  example,  a  subprogram,  excepdon  or  objecL  It  may  not  be  a  nitnan 
number  or  string  constant  The  pragma  must  appear  af^  the  declaradtm  of  the  ennty  in  ^  Mme  package 
specificadon. 

The  effect  of  the  pragma  is  to  cause  the  string-constant  to  be  used  in  the  generated  assembly  code  as  an 
external  name  for  the  associated  Ada  ennty.  It  is  the  responsibility  of  the  user  to  guarantee  that  this  string 
constant  is  meaningful  to  the  linkage  editor  and  that  no  illegal  Unkname  clashes  arise. 

This  pragma  has  no  effect  when  applied  to  a  subprogram  or  to  a  renames  declandon;  in  the  !«><«•  case,  no 
warning  mesaage  is  given. 

When  determining  the  maximum  allowable  length  for  the  g«temai  iinif«y>  name,  keep  in  mind  that  the 
compiler  will  genoate  names  for  elaboradon  flags  simply  by  appending  the  suffix  #GOTO.  Therefore,  the 
external  linkage  name  has  5  fewer  significant  characters  than  ^  lower  limit  of  other  tools  that  need  to  process 
the  name  (for  example,  40  in  the  case  of  the  Tartan  Linker). 

Note:  Names  used  as  pragma  LINKAGE_NAME  are  case  sensidve.  For  example. 
aNy_01d_LINKnaine  is  not  equivalent  to  ANY_OLO_LINKNAME.  Therefore,  a  misspelled 
linknatne  will  cause  the  link  to  fail. 

S.JJJ.  Premia  FOREIGN^BODY 

In  addidon  to  pragma  INTERFACE.  Tartan  Ada  supplies  pragma  FOREIGN^BOOY  as  a  way  to  access 
subprograms  in  oihCT  languages. 

Unlike  pragma  INTERFACE,  pragma  FCREIGN_BODY  allows  access  to  objects  and  excepdoos  (in  addidon 
to  subprograma)  to  and  from  ocher  languages. 

There  are  some  restricdons  on  pragma  F0R£IGN_B0DY  duu  are  not  applicable  to  pragma  INTERFACE: 

•  Pragma  FORE  IGN_B0D  Y  must  appear  in  a  non-generic  libiaty  package. 

•  All  objects,  excepdoos  and  subprograms  in  such  a  package  must  be  supplied  by  a  foreign  objea  module. 

•  Types  may  imc  be  dedared  in  s^  a  package. 

Use  of  the  pragma  FOR£IGN_BOOY  dtctates  that  all  stfoptograms.  excepdoos  and  objects  in  the  package  ate 
provided  by  means  of  a  foreign  object  module.  In  order  to  successfully  link  a  program  including  a  foreign  body, 
the  object  module  for  that  body  must  be  provided  to  die  libnty  using  the  ALC40  FOREIGN_BODY  command 
described  in  Secdon  3  J3.  The  pragma  is  of  the  fonm 

prayna  FOREIGN_BOOY  {Language jtame  C,  elaboraaonj-outinejtame]) 

The  parameter  Language  jtame  is  a  string  intended  to  allow  the  compiler  to  identify  the  calling  convendon 
used  by  the  fardpi  module  (but  this  ftmctionaliQf  is  txn  yet  in  operancn).  Cunently,  the  programmer  must 
ensure  that  the  calling  convendon  and  dau  leptesentadon  of  the  foreign  body  procedures  are  compadble  with 
dMse  used  by  the  Tartan  Ada  Gxnpikr  (see  Se^on  6  J).  Subprograms  calted  ^  tasks  should  be  teentratu. 

The  opdonal  elaboration j-outine jtame  siring  argnmem  is  a  iwifage  name  idemifying  a  routine  to  inirialire 
the  package.  The  routine  specified  as  the  elaboration  jouxine  jtame,  which  will  be  called  for  the  elaboration  of 
this  package  body,  must  be  a  global  routine  in  the  objea  module  provided  by  the  user. 

A  specification  that  uaaa  diis  pragma  may  only  subprogram  dedarationa.  objea  dedatadons  that  use 
an  unconstrained  type  mark,  and  number  dedaradons.  Pragmss  may  also  appear  in  the  package.  The  type  mark 
for  an  objea  cantwt  be  a  task  type,  and  the  objea  declaration  must  na  have  an  initial  value  expresaiotL  The 
pragma  most  be  given  prior  to  any  dedaradons  within  the  padeage  specificatioiL  If  die  pragma  is  na  located 
before  the  first  declaradon,  ot  any  restricdoo  on  the  dedaradioos  is  vioiaied.  the  pragma  is  ignored  and  a  warning 
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The  fEmiga  body  is  entirely  responsible  for  initislizing  objects  declared  in  a  package  utilizing  pragma 
:  CR£IGN_300Y.  In  particular,  the  user  should  be  aware  that  the  implicit  initializadons  descnbed  in  LRM  3.2.1 
are  not  done  by  the  compiler.  (These  implicit  inioalizadoos  are  associated  with  objects  of  access  types,  certain 
record  types  and  composite  types  containing  con^xments  of  the  preceding  of  types.) 

Pragma  LINKAGE_NAME  shoold  be  used  for  ail  deciaranoos  in  the  package,  including  any  declaiatiaos  in  a 
nested  package  specification  to  be  snte  that  there  are  no  ermflietinj  itnimTn^  If  pragme  linkaGE_NAME  is 
not  lued.  the  crossHeference  qualifier,  /CROSS^REcERENCE,  (see  Section  4.2)  should  be  used  when  invoking 
the  compiler.  The  resulting  cross'ieference  able  of  should  then  be  inspected  to  determine  that  no 

conflicting  linknames  have  been  assigned  by  the  conpiier  (see  also  Section  AS).  In  the  following  example,  we 
want  to  caU  a  funcdoo  plmn  which  computes  polynomials  and  is  written  in  assembly. 

package  math_functions  b 

pragma  FOREIGN  30DY  ("assembly"); 

Ainction  POLYNOMIAL  (X:  INTEGER)  return  INTEGER; 

—  Ada  spec  matching  the  assembly  routine 
pragma  LINKAGE_NAME  (POLYNOMIAL,  "plmn"); 

—  Force  compiler  to  use  name  "plmn"  when  referring  to  t.his 
—  function 

end  MATH_FUNCTIONS; 

with  MATH_FUNCTIONS;  use  MATH_FUNCTIONS; 

procedure  MAIN  is  " 

X: INTEGER  POLYNOMIAL (10) ; 

—  Will  generate  a  call  to  "plmn" 
begin  . . . 

end  MAIN; 

To  compile,  link  and  run  the  above  program,  you  muse 

1.  QmpUe  MATH_FUNCTIONS 

2.  Compile  MAIN 

3.  Provide  the  objea  module  (for  example,  math .  TOF)  ctmtaining  the  assembled  code  for  plmn 

4.  Issue  the  command: 

9  ALC40  FOREIGN  MATH_FUNCTIONS  MATH. TOF 

5.  Issue  the  command: 

$  ALC40  LINK  MAIN 

Without  Step  4,  an  attempt  to  link  will  produce  an  error  message  infonning  you  of  a «"«««»«;  package  body  for 
MATH_FUNCTIONS. 

Using  an  Ada  body  from  another  Ada  program  library.  The  user  may  compile  a  body  written  in  Ada  for  a 
pacification  into  the  library,  regatdleaa  the  language  specified  in  the  pragma  in  the  spedficatioa. 

Thta  capability  is  useful  for  rapid  prototyping,  where  an  A/^  package  may  serve  to  provide  a  «"*«»»«***<  response 
Ibr  the  ftmcthmality  that  a  foreign  body  may  eventually  produce.  It  also  allows  the  user  to  replace  a  foreign  body 
with  an  Ada  body  without  recompilmg  the  specification. 

TbeuacrcaneithercompileanAdabody  into  the  Ubcaty,  or  use  the  command  ALC 40  FOREIGN^BODY  (see 
Secdon  3  J  J)  to  use  an  Ada  body  from  another  lihtiiy.  The  Ada  body  fiom  another  Ubraiy  must  have  been 
compiled  under  an  identical  spedficadoii.  The  prspoa  LINKAGE_NAM£  must  have  been  applied  to  ail  entities 
decland  in  the  specification.  The  only  way  to  spediy  the  Imkname  for  the  elaboradon  routine  of  an  Ada  body  is 
with  the  pnigma  FOREIGN_BOOY. 
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5.1J.  Pragma  MEMORY_SI2E 

This  secQon  deoils  the  procedure  for  compilstioa  of  a  new  uniL  such  as  pragma  M£MCRY_3IZZ.  with  a 
system  pragma.  The  new  unit  must  be  compil^  into  a  library  that  contains  pa^ge  SYSTEM.  For  most  users, 
the  ST.\NDARO_PACKAGES  library  will  be  the  library  that  also  includes  package  SYSTEM. 

1.  Thaw  STANDARD_PACKAGES .  SPEC. 

2.  Compile  this  unit  into  STANDARO_P.ACKAGES .  ROOT.  This  step  updates  package  SYSTEM . 

3.  Freeze  STANDARD_PACKAGES .  SPEC. 

Following  these  steps  will  allow  yon  to  modify  the  maxiimun  address  space. 
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5.2.  IMPLEMENTATION-DEPENDENT  ATTRIBUTES 

No  implemenutioa-dqjendeat  attiibutes  are  cuirently  supported. 


53.  SPECIFICATION  OF  THE  PACKAGE  SYSTEM 

The  parameter  values  specified  for  the  Texas  Instruments  C40  processor  family  target  in  package  SYSTEM 
(LRM  13.7.1  and  Aimex  Q  are: 

package  SYSTEM  is 

type  ADDRESS  is  new  INTEGER; 
type  NAME  is  (TI320C40); 

SYSTEM_NAME  :  constant  NAME  TI320C40; 

STORAGE  UNIT  :  constant  32; 

MEMORY_SIZE  :  constant  16#FFFrFFFF#; 

MAX  INT  :  constant  2_147_483_647; 

MIN“INT  :  constant  -MAX_INT  -  1; 

MAX_DIGITS  :  constant  9; 

MAX  MANTISSA  :  constant  31; 

FINE  DELTA  :  constant  2#1.0#e-31; 

tick”  :  constant  0.00006103515625  —  2**  (-14) 

subtype  PRIORITY  is  INTEGER  range  10  ..  100; 

DEFAULT  PRIORITY  :  constant  PRIORITY  PRIORITY' FIRST; 

RUNTIME“ERR0R  :  exception; 

end  SYSTEM;" 
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5.4.  RESTRICTIONS  ON  REPRESENTATION  CLAUSES 

The  following  sectioos  explain  the  basic  restiictions  for  representation  specifications  followed  by  additional 
restrictions  applyii^  to  specific  kinds  of  clauses. 

5.4.1.  Basic  Restriction 

The  basic  restriction  on  representation  spedficatiois  (LRM  13.1)  is  that  they  may  be  given  only  for  types 
declared  in  tenns  of  a  type  definition,  excluding  a  GZNERIC_TY?E_CE?INITION  (LRM  12.1)  and  a 
?RIVAT£_TY?E_DEFINITION  (LRM  7.4).  Any  representation  clause  in  violation  of  these  rules  is  not  obeyed 
by  the  compiler,  an  exror  message  is  issued. 

Further  restrictions  are  explained  in  the  following  sections.  Any  representation  clauses  violating  those 
restrictioas  cause  compilation  to  stop  and  a  diagnostic  message  U)  be  issued. 

5.42.  Length  Clauses 

Length  clauses  (LRM  132)  are.  in  general,  supported.  The  following  sections  detail  use  and  restrictions. 
5.4JJ.  Size  Spteifleadonsfor  Types 

The  rules  and  restrictions  for  size  spedfications  applied  to  types  of  various  classes  are  described  below. 

The  following  principle  rales  apply: 

1.  The  size  is  specified  in  bits  and  must  be  given  by  a  static  expression. 

2.  The  specified  size  is  taken  u  a  mandate  to  store  objects  of  the  type  in  the  given  size  wherever  feasible. 
No  attempt  is  made  to  store  values  of  the  type  in  a  smaller  size,  even  if  possible.  Tbe  following  rules 
apply  with  regard  to  feasibility: 

•  An  object  that  is  not  a  component  of  a  composite  object  is  allocated  with  a  size  and  alignment  that 
is  referable  on  the  target  machina  (i.e.,  no  attempt  is  made  to  create  objects  of  noo>referable  size  on 
the  stack).  If  such  nack  compression  is  desired,  it  can  be  achieved  by  the  user  by  combining 
multiple  stack  variables  in  a  composite  object;  for  example: 

type  MY  ENUM  is  (A, B); 
for  MY_ENUM'SIZE  use  1; 

V,W:  MY_ENUM;  —  will  occupy  two  storage 
”  —  units  on  the  stack 

—  (if  allocated  at  all) 
type  REC  is  record 
V,W:  MY_ENUM; 
end  record; 
pragma  PACK (REC) ; 

0:  REC;  —  will  occupy  one  storage  unit 

•  A  formal  parameter  of  the  type  is  sized  according  to  calling  conventions  rather  than  size  spedfica* 
tions  of  tte  type.  Appropriate  size  conversions  upon  parameter  passing  take  place  automatically 
and  ate  transparent  to  the  user. 

•  Adjacem  bits  to  an  object  that  is  a  compooea  of  a  composite  ofajecL  but  adiose  size  is  non* 
reftrabie,  may  be  afifected  by  asrignmenis  to  the  object  unless  drew  bits  are  occupied  by  other 
components  of  the  composite  objea  (ire.,  whenever  possible,  a  compooea  of  non-retobie  size  is 
made  icferabk). 

In  all  cases,  the  compiler  generates  conea  code  for  all  opeiatioos  on  objects  trf  the  type,  even  if  they  are 
stored  with  differing  repteseaatmoal  sizes  in  differem  contexts. 

Note:  A  size  spedficstion  carrnot  be  used  to  force  a  certain  size  in  value  operations  of  the  type;  fw 
example: 
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zype  MY_:nT  is  range  0.. 65535; 
for  My_INT'SIZE  use  16;  —  o.k. 

A,B:  MY_INT; 

...A  3...  —  this  operation  will  generally  be 

—  executed  on  32-bit  values 

3.  A  size  specification  for  a  type  q)ecifies  the  size  for  objects  of  this  type  and  of  all  its  subtypes.  For 
components  of  composite  types,  whose  subtype  would  allow  a  shorter  representation  of  the  component, 
no  attempt  is  made  to  take  advantage  of  such  shorter  lepiesentations.  In  contrast,  for  types  without  a 
length  clause,  such  components  may  be  represented  in  a  lesser  number  of  bits  than  the  number  of  bits 
required  to  represent  all  values  of  the  type.  For  example: 

type  MY_INT  is  range  0..2**15-1; 
for  MY_INT'SIZE  use  16;  —  (1) 
subtype  SMALL_MY_INT  is  MY_INT  range  0..255; 
type  R  is  record 

.X:  SMALL_MY_INT; 
end  record; 

the  camponent  R.X  will  occupy  16  bits.  In  the  absence  of  the  length  clause  at  (1).  R.X  may  be 
represenred  in  32  bits. 

Size  specifications  for  access  types  must  coincide  with  the  default  size  chosen  by  the  compiler  for  the  type. 

Size  :q)ecificatioos  are  not  supported  for  floating>poim  types  or  task  types. 

No  useful  effea  can  be  achieved  by  using  size  specifications  for  these  types. 

5.4  JJ,  Siz0  Speeifleadonfor  Scalar  Types 

The  specified  size  must  accommodate  ail  possible  values  of  the  type  including  the  value  0.  even  if  0  is  not  in 
the  range  of  the  values  of  the  type.  For  numeric  types  with  negative  values,  the  number  of  bits  must  account  for 
the  sign  bit.  No  skewing  of  the  representation  is  attempted.  Thus, 
type  MY_INT  is  range  100.. 101; 
requires  at  least  7  bits,  although  it  has  only  two  values,  while 
type  MY_INT  is  range  -101.. -100; 
requires  8  bits  to  account  for  the  sign  bit 

A  size  ^tedficatioo  for  a  real  type  does  not  affea  the  accuracy  of  operations  on  the  type.  Such  influenoe 
should  be  exerted  via  the  ACCURACY_DEFINITION  of  the  type  (LRM  3.5.7, 3J.9). 

A  size  specification  for  a  scalar  type  may  not  specify  a  size  larger  than  the  largest  operetion  size  supported  by 
the  target  axchitecinre  for  the  respective  class  of  values  of  the  type. 

5.4 JJ.  Slat  Spadfleation  for  Array  Types 

A  size  spedfication  for  an  anay  type  must  be  large  enou^  to  accommodate  all  componens  of  die  array  under 
the  densest  paddng  strategy.  Any  alignment  constraina  on  the  component  type  (see  Se^on  5.4.7)  must  be  met. 

The  size  of  die  component  type  cannot  be  infiuenced  by  a  length  clause  for  an  amy.  Within  the  limits  of 
representing  all  posaibie  values  of  the  componma  subtype  (but  not  necessarily  of  its  type),  the  represeiuation  of 
enmpntmntx  may,  howevcT,  be  reduced  to  the  nHnmmtn  number  of  bits,  unless  the  componem  type  carries  a  size 
specification. 

If  there  is  a  size  spedficatian  for  the  component  type,  but  not  for  the  array  type,  the  component  size  is 
rounded  up  to  a  refenbie  size,  unless  pragma  PACK  is  givoL  This  rule  applies  even  to  boolean  types  a  other 
types  that  require  only  a  single  bit  for  tte  representation  d  all  values. 
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5.4J.4.  Size  Sptcificadon  for  Record  Types 

A  size  specification  for  a  record  type  does  not  influence  the  de&ult  type  mapping  of  a  record  type.  The  size 
must  be  at  least  as  large  as  the  number  of  bits  detennined  by  type  mapping.  Influence  over  packing  of 
components  can  be  exerted  by  means  of  (partial)  record  represemadon  clauses  or  by  pragma  PACK. 

Neither  the  size  of  component  types,  nor  the  representadon  of  component  subtypes  can  be  influenced  by  a 
length  clause  fm  a  record. 

The  only  implementadon-dependent  components  allocated  by  Tartan  Ada  in  records  contain  either  dope 
infonnadon  for  arrays  whose  bounds  depend  on  discriminants  of  the  record  or  reladve  of&ets  of  components 
within  a  record  layout  for  record  components  of  dynamic  size.  These  implemenadon-dependent  components 
cannot  be  named  or  sized  by  the  user. 

A  size  spedficadon  cannot  be  applied  u>  a  record  type  with  components  of  dynamically  determined  size. 

Note:  Size  spedficadona  for  records  can  be  used  only  to  widen  the  representadon  accomplished  by  padding  at 
the  beginning  or  end  of  the  record.  Any  narrowing  of  the  representadon  over  default  type  mapping  must  be 
accomplished  by  representadon  clauses  or  pragma  PACK. 

5.4 JJ.  SpeeifieodoH  of  CoUeetion  Sizes 

The  spedficadon  of  a  collecdon  size  causes  the  coilecdon  to  be  allocated  with  the  specified  size.  It  is 
expressed  in  storage  units  and  need  not  be  stadc,  refer  to  package  SYSTE.M  for  the  meaning  of  storage  units. 

Any  attempt  to  allocate  more  objects  than  the  collecdon  can  hold  causes  a  STORAGE_ERROR  excepdon  to  be 
raised.  Dynamically  sized  records  or  arrays  may  carry  hidden  adminiseradve  storage  requiremetus  that  must  be 
accounted  for  as  pan  of  the  collecdon  size.  Moreover,  alignment  constraints  on  the  type  of  the  allocated  objects 
may  make  it  impossible  to  use  all  memory  locadons  of  the  allocated  collecdoiL  No  matter  what  the  requested 
objea  size,  the  allocator  must  allocate  a  minimum  of  2  words  per  object  This  lower  limit  is  necessary  for 
adminisffadve  overhead  in  the  allocator.  For  example,  a  request  of  5  wi^  results  in  an  allocadon  of  5  words;  a 
request  of  one  (1)  word  results  in  an  allocadon  of  2  words. 

In  the  absence  of  a  spedficadon  of  a  coilecdon  size,  the  collecdon  is  extended  automadcally  if  more  objects 
are  allocated  than  possible  in  the  collecdon  originally  allocated  with  the  compiler-established  default  size.  In  this 
case.  STORAGE_ERROR  is  raised  only  when  the  available  target  memory  is  exhausted.  If  a  collecdon  size  of 
zero  is  specified,  no  access  collecdon  is  allocated. 

S.4J.6.  Spedfication  of  Task  Activation  Size 

The  spedficadon  of  a  task  acdvadon  size  causes  the  task  acdvadon  to  be  allocated  with  the  specified  size.  It 
is  exptes^  in  storage  uruts;  refer  to  package  SYSTEM  for  die  meaning  of  storage  units. 

Any  attempt  to  exceed  the  acdvadon  size  during  execudon  causes  a  STORAGE_ERROR  excepdon  to  be 
raised.  Unlike  coUecdons.  there  is  no  extension  of  task  acdvadons. 

S.4J.7.  Specification  of  ’  SMALL 

Only  powen  of  2  are  allowed  for  '  SMALL. 

The  Imigth  of  the  representadon  may  be  affocted  by  this  spedficadon.  If  a  size  spedficadon  is  also  given  for 
the  type,  the  size  spedficadon  takes  precedence;  it  must  th»  be  possible  to  accommodate  the  spedficadon  of 
'  SMALL  within  the  ^ledfied  size. 


5.43.  Enumeration  Representation  Clauses 

For  enumeradon  representadon  clauses  (LRM  13  J),  die  following  restricdons  apply: 

•  The  intetnai  codes  specified  for  the  literals  of  the  enumendon  type  may  be  any  integer  value  between 
INTEGER'  FIRST  and  INTEGER'  LAST.  It  is  strongly  advised  that  you  do  not  provide  a  lepresentadon 
clause  that  merely  duplicates  the  default  mapping  of  enumeradon  types  which  assigns  consecudve  numbers 
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in  ascending  order  starting  with  zero  (0).  Unnecessary  runtime  cost  is  incurred  by  such  dupUcadon.  It 
should  be  noted  that  the  use  of  attributes  on  enumeradon  types  with  user-specified  encodings  is  cosUy  at 
runtime. 

•  Array  types,  whose  index  type  is  an  enumeradon  type  with  non-condguous  value  encodings,  consist  of  a 
condguous  sequence  of  components.  Indexing  into  the  array  involves  a  runtime  transladon  of  the 
value  into  the  =<dre3poading  posidon  value  of  the  enumeradon  type. 

5.4.4.  Record  Representation  Clauses 

The  alignment  clause  of  record  reptesenudon  clauses  (LRM  13.4)  is  observed. 

Stadc  objects  may  be  aligned  at  powers  of  2.  The  specified  alignment  becomes  the  miniminTi  alignment  of 
the  record  type,  unless  the  minimum  alignmem  of  the  record  forced  by  the  componem  allocadon  and  the 
minimum  alignment  requirements  of  the  components  is  already  more  stringent  than  the  specified  aiignm^f 

The  component  clauses  of  record  representadon  clauses  are  allowed  only  for  components  and  discriminants 
of  stadcally  determinable  size.  Not  all  comp<»ents  need  to  be  present.  Componem  for  components  of 
variam  parts  are  allowed  only  if  the  size  of  the  record  type  is  stadcally  determinable  for  every  variant. 

The  size  specified  for  each  componem  must  be  suffidem  to  allocate  all  possible  values  of  the  componem 
subtype,  but  not  necessarily  the  componem  type.  The  locadon  specified  must  be  compadble  with  any  alignmem 
constraints  of  the  componem  type;  an  alignmem  constraim  oa  a  componem  type  may  cause  an  implicit  alignmem 
constraim  on  the  recmd  type  its^. 

If  some,  but  not  all,  discriminants  and  components  of  a  record  type  are  described  by  a  component  clause,  the 
discriminants  and  components  without  componem  clauses  are  allocated  after  those  with  componem  clauses;  no 
attempt  is  made  to  utilize  gaps  left  by  the  user-provided  allocadon. 

5.4  J.  Address  clauses 

Address  clauses  (LRM  13  J)  are  supported  with  the  following  lestricdtHis: 

•  When  applied  to  an  object,  an  address  clause  becomes  a  linker  direcdve  to  allocate  the  object  at  the  given 
address.  For  any  object  not  declared  immediately  within  a  top-level  library  package,  the  address  gia«M  is 
meaningless. 

•  Address  clauses  applied  to  local  packages  are  not  supported  by  Tartan  Ada.  Address  clauses  applied  to 
library  packages  are  prohibited  by  the  syntax;  therefore,  an  address  clause  can  be  applied  to  a  package  only 
if  it  is  a  body  smb. 

•  Address  clauses  applied  to  subprograms  and  casks  are  implemented  according  to  the  LRM  rales.  When 
applied  to  an  entry,  the  specified  value  identifies  an  interrupt  in  a  manwr  customary  for  the  target. 
Immediately  after  a  teak  is  created,  a  ttmtime  call  is  made  for  each  of  its  entries  having  an  address  clause, 
estthlishing  the  proper  binding  between  the  entry  and  the  imenupL  A  specified  address  must  be  an  Ada 
static  expression. 

Note:  Geadng  an  overlay  of  two  objects  by  means  of  address  clauses  is  possible  with  Tartan  Ada. 
However,  sudi  overlays  (sriiich  are  considered  erroneous  by  the  Ada  LRM  i3J(8))  will  not  be 
recognized  by  the  compiler  as  an  aliasing  that  prevents  certain  optimizations.  Therefore,  problems 
may  arise  if  reading  and  writing  of  the  two  overlaid  objects  are  intermingled.  For  example,  if 
variables  A  and  B  are  overlaid  by  means  of  address  clauses,  the  Ada  code  sequence: 

A  5; 

B  7; 

if  A  -  S  Chen  raise  SURPRISE;  end  if; 
may  well  raise  the  exception  SURPRISE,  since  the  compiler  believes  the  value  of  A  to  be  5  even  after 
the  assignmem  to  B. 
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5.4.6.  Pragma  PACK 

Pragma  PACK  (LRM  13. 1)  is  supported.  For  details,  refer  to  the  following  sections. 

5.4.6.I.  Pragma  PACK  for  Arrays 

If  pragma  PACK  is  applied  to  an  anay,  the  densest  possible  representation  is  chosen.  For  details  of  packing, 
refer  to  the  explanation  of  size  spedficadons  for  atrays  (Secdon  5.4.2  J). 

If,  in  addidon,  a  length  clause  is  applied  to  the  anay  type,  the  pragma  has  no  effect,  since  such  a  length  clause 
already  uniquely  detennines  the  anay  packing  me±od. 

If  a  length  clause  is  applied  to  the  component  type,  the  anay  is  packed  densely,  observing  the  component’s 
length  clause.  Note  that  the  component  length  clause  may  have  the  effect  of  preventing  the  compiler  from 
packing  as  densely  as  would  be  the  default  if  piagma  PACK  is  applied  where  there  was  no  length  clause  given  for 
the  component  type. 

5.4.6 Tht  Prodejmsd  Type  STRING 

Package  ST.ANOARD  applies  pragma  PACK  to  the  type  STRING.  However,  because  type  character  is  deter¬ 
mined  to  be  32  bits  on  the  C40,  this  applicadon  results  in  one  character  per  word. 

5.4.6 J.  Pragma  PACK  for  Records 

If  pragma  PACK  is  applied  to  a  record,  the  densest  possible  lepresentadon  is  chosen  that  is  compadble  with 
the  s^  and  alignment  constraints  of  the  individual  component  types.  Pragma  PACK  has  an  effect  only  if  the 
sizes  of  some  component  types  ate  specified  explicitly  by  size  spedficadoas  and  ate  of  non-referable  namte.  In 
the  absence  of  pragma  PACIC  such  components  generally  coasume  a  referable  amount  of  space. 

It  should  be  noted  that  the  default  type  mapping  for  rectsds  maps  componenis  of  boolean  cr  other  types  that 
require  only  a  single  bit  to  a  sin^e  bit  in  the  record  layout,  if  there  are  multiple  such  components  in  a  record. 
Otherwise,  it  allocates  a  referable  amount  of  storage  to  tite  componenL 

If  pragma  PACK  is  applied  to  a  record  for  which  a  record  representation  clause  has  been  given  detailing  the 
allocation  of  some  but  na  all  components,  the  pragma  PACK  affects  only  the  components  whose  allocation  has 
not  been  detailed.  Moreover,  the  strategy  of  not  utilizing  gaps  between  explicitly  allocated  componenis  still 
applies. 

5.4.7.  Minimal  AUgnmtntfor  Types 

Certain  alignment  properties  of  values  of  certain  types  are  enforced  by  the  type  mapping  rules.  Any  represen¬ 
tation  spedficatioa  that  cannot  be  satisfied  within  thiw  consirainis  is  not  oteyed  by  the  compiler  and  is  ap¬ 
propriately  diagnosed. 

Alignmeru  consninis  are  caused  by  properties  of  the  target  architecnire.  most  notably  by  the  ci4}abili9  to 
exttaa  non-aligned  componem  values  from  comiwsitB  values  in  a  reasonably  effidem  manner.  Typically, 
restrictions  exist  that  make  extraction  of  values  that  cross  certain  address  boundaries  very  expensive,  especially 
in  contexts  involving  array  indexing.  Permitting  data  layouts  that  require  such  complicate  extractions  may 
impact  code  quality  on  a  broader  scale  than  merely  in  the  local  context  of  such  extractions. 

Instead  of  describing  the  precise  algorithm  of  esuhliahing  the  minimal  alignmem  of  types,  we  provide  the 
general  rule  that  is  being  enforced  by  the  alignmem  rules: 

•  No  objea  of  scalar  type  finduding  components  or  subcomponents  of  a  composite  type)  may  span  a 
target-dependem  addrM  boundary  that  would  mandate  an  extraction  of  die  object’s  value  to  be  performed 
by  two  or  more  extractions. 
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5  j.  IMPLEMENTATION-GENERATED  COMPONENTS  IN  RECORDS 

The  only  impiementation-depeadent  components  allocated  by  Tartan  Ada  in  records  contain  dope  information 
for  arrays  whose  bounds  depend  on  disaiminaats  of  the  record.  These  components  cannot  be  named  by  the  user. 

5.6.  INTERPRETATION  OF  EXPRESSIONS  APPEARING  IN  ADDRESS  CLAUSES 

Section  13J.1  of  the  LRM  describes  a  syntax  for  assodating  inteiropts  with  task  entries.  Tartan  Ada 
implements  the  address  clause 

for  toentry  use  at  intIO; 

by  associating  the  interrupt  specified  by  intID  with  the  toentry  entry  of  the  task  containing  this  address 
clause.  The  interpreutian  of  int  ID  is  both  machine  and  cmi^iler  dependent. 

5.7.  RESTRICTIONS  ON  UNCHECKED  CONVERSIONS 

Tartan  supports  UNCHECK£0_C0NV£RSI0N  as  documented  in  Section  13.10  of  the  LRM.  The  sizes  need 
not  be  the  same,  nor  need  they  be  known  at  compile  time.  If  the  value  in  the  source  is  wider  than  that  in  the 
target,  the  source  value  will  be  truncated.  If  narrower,  it  will  be  zero-extended.  Calls  on  instantiations  of 
UNC.HECKED^CONVERSION  are  made  inline  automadcally. 

5.8.  IMPLEMENTATION-DEPENDENT  ASPECTS  OF  INPUT-OUTPUT  PACKAGES 

Tartan  Ada  supplies  the  predefined  input/output  packages  0IRECT_I0.  SEQUENTIAL^IO,  TEXT^IO.  and 
LOW_LEVEL_IO  as  required  by  LRM  Qiapter  14.  However,  since  the  C40  chip  is  used  in  embedded  applica- 
tions~lacking  both  standard  I/O  devices  and  file  systems,  the  functiooality  of  DIR£C7_I0,  SEQUENTIAL_IO. 
and  TEXT_IO  is  limited. 

DIRECT_IO  and  SEQUENTIAL_IO  raise  USE_ERROR  if  a  file  open  «  file  access  is  attempted.  TEXT_IO 
is  supported  to  CURRENT_OUTPUT  and  from  CURREN7_INPUT.  A  routine  that  takes  explicit  file  names  raises 
USE  ERROR. 
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5.9.  OTHER  IMPLEMENTATION  CHARACTERISTICS 

The  following  infonnadon  is  supplied  in  addidon  to  that  required  by  Appendix  F  to  MIL-STD-18  ISA. 

5.9.1.  Definition  of  a  Main  Program 

Any  Ada  library  subprogram  unit  may  be  designated  the  main  program  for  purposes  of  linking  (using  the  Ada 
librarian's  LINK  subcommand)  provided  that  the  subprogram  has  no  parameters. 

Tasks  initiated  in  imported  library  units  follow  the  same  rules  for  tenninadon  as  other  tasks  [described  in 
LRM  9.4  (6-10)].  Spediically.  these  tasks  ate  not  termiruted  simply  because  the  main  program  has  terminated. 
Terminate  altemadves  in  selective  wait  statements  in  library  tasks  ate  therefore  strongly  recommended. 

5.92.  Implementation  of  Generic  Units 

All  instandadons  of  generic  units,  except  the  predefined  generic  UNCH£CK£0_CCNVERSICN  and 
UNC.H£CK£3_DEALLOCATION  subprogiams,  are  implemented  by  code  dupiicadons.  No  attempt  at  sharing 
code  by  muldple  instandadons  is  made  in  dda  release  of  Tartan  Ada. 

Tartan  Ada  enforces  the  restticdon  that  the  body  of  a  generic  unit  must  be  compiled  before  the  unit  can  be 
ipaiantiatari  It  does  noc  impose  the  restricdoD  that  the  spedficadon  and  body  of  a  generic  unit  must  be  ptxrnded 
as  pan  of  the  *«Tie  compiladotL  A  recompiladon  of  the  body  of  a  generic  unit  will  cause  any  units  that 
this  generic  uidt  to  become  obsolete. 


5 .92.  Implementation-Defined  Characteristics  in  Package  STANDARD 

The  impletnenudon-dependem  characmrisdcs  for  C40  in  package  Standard  (Annex  Q  are: 
package  STANDARD  is 

type  INTEGER  is  range  -2_147_483_648  ..  2_147_483_647; 

type  FLOAT  is  digits  6  range  -16#0 . 1000_00#E+33  ..  1640  .FFFF_? F#E+32; 

type  LONG_FLOAT  is  digits  9  range  -16#0.1000_000_0#E-^33  .. 

16#0.FFFF  FFFF_0#E+32  ; 

type  DURATION  is  dei&l  0.0001  range  -86400.0  ..  36400.0; 

—  DURATION' SMALL  -  2#1.0#E-14  (that  is,  5.103516£’=  sec) 

end  STANDARD; 

5S.4.  Attributes  of  Type  DURATION 

The  type  DURATION  is  with  the  following  characteristics: 


Attribute 

Value 

DURATION' DELTA 

0.0001  sec 

DURATION' SMALL 

6.103S16E'’  sec 

DURATION' FIRST 

-86400.0  sec 

DURATION' LAST 

86400.0  sec 
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5.9.5.  Values  of  Integer  Attributes 

Tanan  Ada  supports  the  predefined  integer  type  INTEGER.  The  range  bounds  of  the  predefined  type 
INTEGER  are: 


Attribute 

Value 

INTEGER' FIRST 

-2**31 

INTEGER' LAST 

2**31-1 

The  range  bounds  for  subtypes  declared  in  package  TEXT_IO  are: 


Attribute 

Value 

COUNT' FIRST 

0 

COUNT' LAST 

INTEGER'  LAST  -  1 

POSITIVE_COUNT' FIRST 

1 

POSITIVE_COUNT' LAST 

INTEGER' LAST  -  1 

FIELD' FIRST 

0 

FIELD' LAST 

240 

The  range  bounds  for  subtypes  declared  in  package  DIR£CT_IO  are: 


Attribute 

Value 

COUNT' FIRST 

0 

COUNT' LAST 

INTEGER' LAST 

POSITIVE_COUNT' FIRST 

1 

P0SITIVE_C0UNT' LAST 

COUNT' LAST 
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5.9.6.  Values  of  Floating-Point  Attributes 

Tanm  Ada  supports  the  predefined  fioating-point  types  FLOAT  and  LCNG_FLOAT. 

In  addidoo.  a  set  of  standard  library  packages  provides  support  for  a  aon*Ada  “double  piedsioo’’  16-deciinal 
digit  float  type.  EXTEND  EO_FLOAT.  Please  refer  to  Secdon  8.2  for  details.  This  type  could  not  be  supported  as 
a  predefined  type  due  to  Ada's  “4*8“  rule  (LRM  3.5.7.?)  that  relates  '  DIGITS  to  the  range  of  the  omphin*. 
expooenL  Under  this  rule,  the  EXTENCED_FLCAT  is  indisdnguishable  fron  the  LONG  FLOAT  type. 


Attribute 

Value  for  FLOAT 

DIGITS 

6 

MANTISSA 

21 

EMAX 

84 

EPSILON 

16#0.1000_00#E-4  (apprn»im«teiy  9J3674E-07) 

SMALL 

16#0.8000_00»E*21  (approximately  2J8494E-26) 

LARGE 

16#0JFFF/_F8#E-f21  (approximately  1.93428E't>25) 

SAFE^EMAX 

12S 

SAFE^SMALL 

16#0.4000_00#E*31  (approximately  1.17S49E-38) 

SAFE_LARGE 

16#0.1FFF_FF«E<i>32  (approximately  4J5353E-t>37) 

FIRST 

•16#0.1000.(X)#E-*>33  (approximately  •3.40282E4'38) 

LAST 

16#0JFFF_FWE+32  (^tproximately  3.40282E-«>38) 

MACHINE_RADIX 

2 

.MACHINE_MANTISSA 

24 

MACHINE_EMAX 

128 

MACHINE_EMIN 

•125 

MACHINE_ROUNDS 

FALSE 

MACH I NE_OVE RFLOWS 

TRUE 
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The  Ada  attributes  are  insufficient  for  completely  describing  floating  point  numbers,  especially  with  non- 
symmetric  iwrhine  exponent  and  machine  mantissa  ranges.  For  example.  MACHINE_£MAX  and 
MACHIN£_EMIN  are  defined  such  that  both  the  full  mantis.sa  range  and  the  negative  of  any  value  must  be 
supptmed  in  the  floating  fbnnaL  This  fails  to  other,  less  restrictive  exponent  limits. 

Additional  (missing)  properties  ate  provided  in  the  table  below.  The  table  is  informational;  there  are  no 
addidonai  attributes  conespooding  to  thM  values  supplied  by  Tanan  Ada.  In  the  table.  POS_MACHlNE_£MAX. 
NEG_MACHINE_EMAX,  POS_MACHINE_EMIN.  NEG_MACHINE_EMIN  ate  defined  as  the  posidve  and  oega- 
dve  floating  value  extremes  for  the  ma^-hing  exponent  such  that  the  full  manri.ssa  range  is  still  supported  (but  no 
guarantees  ate  made  that  the  negsdve  of  any  value  is  sdll  representable).  P0S_MA.CHINE_VERY_EMAX, 
NEG_MACHINE_VERY_EMAX,  POS_MACHINE_VERY_EMIN.  NEG_MACHINE_VERY_EMIN  are  defined  as 
positive  and  negative  floating  value  extremes  for  iht  marhine  exponem  such  that  at  least  one  floating  value  is 
representable.  MOST_POSITIVE.  LEAST_POSITIVE.  MOST_NEGATI'/E.  and  1EAST_NEGATIVE  are 
abMluie  extremes  possible  in  the  floating  format. 


Property 

Value  for  FLOAT 

POS^MACH INE_EMAX 

128 

NEG_MACH INE_£MAX 

128 

POS_MACHINE_EMIN 

•126 

NEG_MACHINE_EMIN 

•125 

POS_MACH INE_VERY_EMAX 

128 

NEG_MACHINE_VERY_EMAX 

129 

POS_MACHINE_VERY_EMIN 

•126 

NE  G_MACH INE_VERY_EMIN 

•126 

MOST_POSITIVE 

l6#0fFFF_FRffi+32  (»  '  LAST,  approx  3.40282E+38) 

LEAST_POSITIVE 

16#2.0#E-32  (approx  5.87747E-39) 

MOST_NEGATIVE 

-l6#O.l00O_0O#B+33  («  '  FIRST,  approx  -3.40282E+38) 

LEAST_NEGATIVE 

•l6#l{XXX)_01#E-32  (approx  -5.87747E-39) 
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Attribute 


Value  for 


MANTISSA 


EPSILON 


LARGE 


SAFE_EMAX 


SAFE_SMALL 


S AF  E_LARGE 


FIRST 


MACHINE_RADIX 


MACHINE_MANTISSA 


MACHINE_EMAX 


MACHINE_SM1N 


MACHINE_ROUNDS 


MACHINE  OVERFLOWS 


16#0.4000_0000_0#E-7  (approximately  9.31322575E-10) 


16#0.8000.0000_0#E-31  (approximately  235098870E-38) 


16#OJFFF_FFFE_0#E+31  (approximately  2.12676479E+37) 


125 


16#0.4(X)0_0(XX)_0#E*31  (approximately  1.17S494351E-38) 


16#0.1FFF_FFFF_C#E+32  (approximately  4.^3529587E+37)  | 


•16#0.1(XX)_(XXX)_0#E^33  (approximately  •3.40282367E<i>38) 


I6#0JFFF_FFFF_0#E-t-32  (approximately  3.40282367E-«-38) 


FALSE 
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The  Ada  attributes  ate  iosufSciem  for  completely  describing  floating  point  numbers,  especially  with  non* 
symmetric  machine  exponem  and  machine  mantis.sa  ranges.  For  example,  ;'1ACHINE_EMAX  and 
MACHIN£_£MIN  are  de&ed  such  that  both  the  hill  range  and  the  negative  of  any  value  must  be 

supponed  in  the  floating  fonnat.  This  fails  to  document  other,  less  restrictive  exponent  limits. 

Additional  (missing)  properties  are  provided  in  the  table  below.  The  table  is  infonnational;  there  are  no 
additioaal  attributes  corr»p<mding  to  these  values  supplied  by  Taitan  Ada.  In  the  table.  POS_MACHlNE_£MAX. 
NEG_MAC.HINE_EMAX,  POS_MAC.HINE_EMIN,  NEG_MACHI.ME_EMIN  ate  defined  as  the  positive  and  nega¬ 
tive  floating  value  extremes  for  the  exponem  such  that  the  full  mantissa  range  is  still  supported  (but  no 

guarantees  are  made  that  the  negative  of  any  value  is  still  represenuble).  POS_MACHINE_V£RY_£max. 
NEG_MAC.HINE_VERY_EMAX,  POS_MACHINE_VERY_EMIN.  NEG_MACHINE_VERY_EMIN  are  defined  as 
the  positive  and  negative  floating  value  extremes  for  the  m«chin*»  exponem  such  that  at  least  one  floating  value  is 
still  represenuble.  MOST_POSITIVE.  LEAST_POSITIVE.  .MOST_NEGATIVE.  and  LEAST_N£GAT:ve  ate 
the  abMlute  extremes  possible  in  the  floating  fonmaL 


Property 

Value  for  LONG_f  LOAT 

POS_MACHINE_EMAX 

128 

NEG__MACHINE_EMAX 

128 

POS_MACHINE_EMIN 

•126 

NEG_MACHINE_EMIN 

-123 

POS_MACH INE_VERY_EMAX 

128 

NEG_MACHINE_VERY_EMAX 

129 

POS_MACH I NE_VERY_EMIN 

-126 

NEG_MACH INE_VERY_EMIN 

-126 

MOST_POSITIVE 

16#0JFFF_FFFF#E+32  (*  '  LAST,  approx  3.40282367E+38) 

LEAST_POSITIVE 

16#2.0#E.32  (approx  5.87747 175E-39) 

MOST_NEGATIVE 

-16#0.l000_0000#E+33  (»  '  FIRST,  approx  -3.40282367E+38) 

LEAST_NEGATIVE 

-16#2.{X)00_(XX)l#E-32  (approx  -5.87747 176E-39) 
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5.10.  SUPPORT  FOR  PACKAGE  MACHINE_CODE 

Package  MACHINE_CCDE  provides  the  user  with  an  interface  through  which  to  request  the  generation  of  any 
instruction  that  is  available  on  the  C40.  The  implementation  of  paduge  MACHINE_C3DE  is  gmiiar  to  that 
described  in  Section  13.8  of  the  Ada  LRM.  with  several  added  feamres.  Please  refer  to  Appendix  B  for  the 
package  MACHINE_CCDE  spedficadoiL 

5.10  J.  Basic  Information 

As  required  by  LRM.  Section  13.8,  a  routine  which  contains  marhina  code  inserts  may  not  have  any  other 
kind  of  statement,  and  may  not  contain  an  excepnon  handler.  The  only  allowed  declarative  item  is  a  use  clause. 
Comments  pragmas  are  allowed  as  usual. 

5.102.  Instructions 

A  machine  code  insert  has  the  form  TYP£_MARK'  RECORD_AGGREGATE.  where  the  type  must  be  one  of  the 
records  defined  in  package  MACHIN£_CODE.  Package  MACHINE_CCDE  defines  seven  types  of  records.  Each 
has  an  opcode  and  zero  to  six  operands.  These  records  are  adequate  for  the  expression  of  all  insmictions 
provided  by  the  C40. 

5.103.  Operands  and  Address  Modes 

An  operand  consists  of  a  record  aggregate  which  holda  all  the  information  to  spediy  it  to  the  compiler.  All 
operands  have  an  address  mode  and  one  or  more  other  pieces  of  inforpiation.  The  operaiids  correspond  exactly  to 
the  operands  of  the  instrucdon  being  generated 

Each  operand  in  a  machine  code  insert  must  have  an  Address  JdodeJ^ame.  The  address  modes  provided  in 
package  MACHINE_CCDE  provide  access  to  all  address  modes  supported  by  the  C40. 

In  addition,  package  MACHINE_CODE  supplies  die  address  modes  SYMBOLIC_AODR£SS  and 
SYMBOL  I  C_VALUE.  which  aUow  the  user  to  lefn  to  Ada  objects  by  specifying  OBJECT' ADDRESS  as  the 
value  for  the  operand.  Any  Ada  objea  which  has  the  '  ADDRESS  attribute  may  be  used  in  a  symbolic  operand. 
SYMBOLIC_ADDRESS  should  be  used  when  the  operand  is  a  true  address  (e.g..  a  branch  target). 
SYMBOLIC_VALUE  should  be  used  when  the  operand  is  actually  a  value  (i.e..  one  of  the  source  operands  of  an 
ADD  I  instruction). 

When  an  Ada  object  is  used  as  a  source  operand  in  an  instruction  (that  is.  one  from  which  a  value  is  read),  the 
compiler  will  generate  code  which  fetches  the  value  of  the  Ada  objecL  When  an  Ada  objea  is  used  as  the 
desdnadon  operand  of  an  instrucdon,  the  compiler  will  generate  code  which  uses  the  address  ttf  the  Ada  objea  as 
the  desdnadon  of  the  instrucdon. 

5.10.4.  Examples 

The  impletnentadon  of  package  MACHINE_CODE  makes  it  possible  to  specify  both  simple  code 

inserts  such  as 

Two_Opnds'  (LDI,  (Imm,  5),  (Reg,  RO)) 

and  more  complex  inserts  such  as 

Three_Opnds' (ADDI3, 

(Imm,  10), 

(Symbolic_Value,  Array_Var(X,  Y,  27) 'ADDRESS) , 

(Symbolic_Address,  Parameter_l' ADDRESS) ) 

In  the  first  example,  the  compiler  will  emit  the  instrucdon  LDI  5,  RO.  In  the  second  example,  the  compiler 
may  first  emit  an  instrucdon  to  load  the  httmediate  value  10  into  a  register  (d^erxling  on  wheto  the  compiler 
decides  to  make  the  typel  or  type2  three  operand  instrucdon),  next  emit  whatever  instrucdons  are  needed  to  farm 
the  address  of  ARRAY_VAR(X,  Y,  27)  ud  then  emit  the  ADDIS  instrucdon.  If  PARAMETER_1  is  nafound 
in  a  register,  the  compiler  wiU  put  the  result  of  the  ad^don  in  a  temporary  tegistBr  and  then  store  it  to 
PARAMETER_1 ' ADDRESS.  Note  that  the  desdnadon  operand  of  the  ADDIS  instrucdon  is  given  u  a 
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SYMBOI>IC_ADDRESS.  This  holds  true  for  ail  desdnation  operands  that  are  not  also  read  as  source  operands  by 
the  instruction.  SYMBOLIC_VALu£  should  be  used  if  the  operand  is  both  a  source  and  a  destination  as  in  the 
second  operand  of  the  AOOI  instrucdon.  The  various  error  checita  specified  in  the  LRM  will  be  perfonned  on  ail 
compUer-generated  code  unless  they  are  suppressed  by  the  user  (either  through  pragma  SUPPRESS,  or  through 
command  quaiifien). 

5.10  Incorrect  Operands 

Under  some  circumstances,  the  compiler  attempts  to  correct  incorrect  operands.  Three  modes  of  operadon 
axe  supplied  for  package  MACHINE_CODE  to  determine  whether  cotiecdons  are  attempted  and  how  much 
infonnadon  about  the  necessary  correcdons  is  provided  to  the  user.  These  mod«  of  operadtm  are 

/FIXUP-NONE.  /FIXUP-WARN.  and  /FIXUP-QUIET./FIXUP-QUIET  is  the  default 

In  /FIXUP*>NONE  mode,  the  spedficadon  of  incorrect  operands  for  an  instrucdon  is  considered  to  be  a  fatal 
error.  In  this  mode,  the  compiler  will  not  generate  any  extra  instrucdons  to  help  you  to  a  m«ghin<»  code 
inserdon.  Note  that  it  is  sdll  legal  to  use  '  ADDRESS  ctmseracts  as  long  as  the  object  which  is  used  mnrn*  the 
requirements  of  the  instrucdon. 

In  /FIXUP-QUIET  mode,  the  compiler  will  do  its  best  to  correct  the  marhin^  code  if  incotiea  operands  are 
specified.  For  example,  although  it  is  illegal  to  use  a  memory  address  as  the  Haatinatiftn  of  an  ADD  I  instrucdon. 
tte  compiler  will  accept  it  and  cry  to  generate  coneo  code.  In  this  case,  the  compiler  will  load  iruo  a  register  the 
value  found  at  the  memory  addrw  indicated,  use  this  register  in  the  ADDI  instrucdon.  and  then  store  firom  that 
register  back  to  the  desired  memory  locadon. 

Two_Opnds' (ADDI,  (Imm,  10),  (ARI,  ARl)  ) 

will  produce  a  code  sequence  resembling 

LDI  *AR1,  RO 

ADDI  10,  RO 

STI  RO,  *AR1 

The  next  example  illustrates  the  coixecdon  required  when  the  displacement  is  out  of  range  for  the  first 
operand  of  an  ADD  1 3  instrucdon.  The  displacemem  is  first  loaded  imo  one  of  the  index  registers. 

Three_Opnds'  (ADDI3,  (IPDA,  AR3,  32),  (Reg,  RO),  (Reg,  Rl)) 

will  produce  a  code  sequence  resembling 

LDI  32,  IRO 

ADDI3  AR3(IR0),  RO,  Rl 

In  /FIXUP*HARN  mode,  the  compiler  will  also  do  its  best  to  correa  any  incocrea  operands  for  an  instruc- 
doa  However,  a  warning  message  is  issued  stadng  that  the  machine  code  insen  requind  addidooal  marhing 
instrucdons  to  make  its  operands  legal 

5J0.6.  Assumptions  Made  in  Correcting  Operands 

When  compiling  in  /FIXUP-QUIET  or  /FIXUP-WARN  modes,  the  compiler  sitenqKs  to  emit  addidooal 
code  to  move  “the  right  bits”  firom  an  inconea  operud  to  a  regtsier  or  pl^  in  memory  whidi  ia  a  legal 
operand  for  the  requested  instrucdon.  The  compiler  makes  certain  basic  assumpdons  wben  performing  these 
ccwnecdons.  This  secdoo  e3q>lains  the  sssunqKions  nude  by  the  compiler  and  their  implicadona  for  the  generated 
code.  Note  that  if  yon  warn  a  conecdon  which  ia  digexent  from  that  perfonned  by  the  compiler,  you  must  make 
explicit  code  inaerdona  to  petfonn  it. 

For  soutoe  operandst 

•  SYMBOLIC_ADDR£SS  means  thtt  the  address  specified  by  the  'ADDRESS  expressum  ia  used  u  the 
soufoe  bits.  When  the  Ada  objea  gawficd  by  the  '  ADDRESS  insncdoa  ia  bound  to  a  legisier.  it  will 
cnat  a  oompile-tiiiie  error  mesaage  becnise  it  is  not  poenbie  to  “take  the  address”  of  a  regoter. 
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•  SYMBOLIC_V.\LUE  means  tbat  the  value  found  at  the  address  specmed  by  the  '  AECRESS  expression  will 
be  used  as  the  source  bits.  An  Ada  objea  which  is  bound  to  a  register  is  correa  here,  because  the  contents 
of  a  register  can  be  expressed  on  the  C40. 

•  PCREL  indicates  that  the  address  of  the  label  will  be  used  as  the  source  bits. 

•  Any  other  non-register  means  that  the  vedue  found  at  the  address  specified  by  the  operand  will  be  used  as 
the  source  bits. 

For  desdnadoa  operands: 

•  SYMBOLIC_ADDR£SS  means  that  the  desired  destination  for  the  operation  is  the  address  specified  by  the 
'  ADDRESS  expression.  An  Ada  objeo  which  is  bound  to  a  register  is  correct  here:  a  register  is  a  legal 
destination  on  the  C40. 

•  3YMBOLIC_VAL’JE  means  that  the  desired  destination  for  the  operations  is  found  by  fetching  32  bits  fiom 
the  address  specified  by  the  '  ADDRESS  expression,  and  storing  the  result  to  the  address  represented  by  the 
fetched  bits.  This  is  equivalent  to  applying  one  extra  indirection  to  the  address  used  in  the 
SYMBOLIC_.^DRESS  case, 

•  All  other  operands  are  interpreted  as  directly  specifying  the  destination  for  the  operatioiL 

5.10.7.  Register  Usage 

Since  the  compiler  may  need  to  allocate  registers  as  temporary  storage  in  in»ghin«>  code  routines,  there  are 
some  restrictions  placed  on  your  register  usage.  The  cmnpiler  will  automatically  free  all  regisiers  which  are 
volatile  arnoss  a  call  for  your  use  (R0.JR3.  bits  32-39  of  R4.  JIS.  bits  0-7  of  R6.  J17,  bits  32-39  of  R8.  R9  ..  R1 1. 
AR0.AR2.  IRO.  IRl.  BK.  ST.  blE.  RE.  HP.  RS,  RC  RE). 

If  you  reference  any  other  register,  the  compiler  will  reserve  it  for  your  use  until  the  end  of  the  marhine  code 
routine.  The  compiler  will  not  save  the  register  automatically  if  this  routine  is  inline  expanded.  This  means  that 
the  first  reference  to  a  register  which  is  not  volatile  across  calls  should  be  an  instruction  which  saves  its  value  in  a 
safe  place.  The  value  of  the  register  should  be  restored  at  the  end  of  the  marhing  code  routine.  This  rule  will 
help  ensure  correa  operation  of  your  machine  code  insert  even  if  it  is  inline  expanded  in  another  routine. 
However,  the  compiler  will  save  the  register  automatically  in  the  prolog  code  for  the  routine  and  restore  it  in  the 
epilog  code  for  the  routine  if  the  routine  is  not  inline  expanded. 

As  a  result  of  freeing  all  volatile  tegistBrs  for  the  user,  any  parameters  which  were  passed  in  registers  will  be 
moved  to  either  a  non-volatile  register  or  to  memory.  References  to  PARAMETER'  ADDRESS  in  a  machine  code 
insert  will  then  produce  code  that  uses  this  register  or  memory  location.  This  means  that  there  is  a  possibility  of 
invalidating  the  value  of  some  '  ADDRESS  expression  if  the  non-volatile  regisiBr  to  which  it  is  bound  is  as  a 
destination  in  some  later  machine  code  insett  In  thia  case,  any  subsequem  tefetenoes  to  the  '  ADDRESS 
expression  will  cause  the  compiler  to  issue  a  warning  message. 

The  compiler  may  need  Kvetal  registen  to  generate  code  for  operand  cotiectioos  in  machine  code  inserts.  If 
yon  use  all  the  registers,  corrections  will  not  be  possible.  In  general  when  mote  registers  ate  available  to  the 
compiler,  it  is  able  to  generate  better  code. 

5J0.8.  Data  Directives 

Two  spedai  instructions  are  included  in  pwkage  MACHINE_C0DE  to  allow  the  user  to  place  data  into  the 
code  stream.  These  two  iostractioos  are  DATA32  and  DATA64.  Each  of  these  instructions  can  have  1  to  6 
operands. 

DATA32  is  used  to  place  32-btt  dau  into  the  code  stream.  The  value  of  an  integer  or  32-bit  floau  and  the 
addren  of  a  Iritel  are  the  legal  operands  (Le.,  operands  whose  address  mode  is  either  IMM.  FLOATIMM,  or 
SYMBOLIC  ADDRESS  of  an  Ada  label). 
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<<  11  >> 

Three_OpnGs'  (DATA32,  (Syitvbolic_Adaress, 

( Symbolic_Address , 

( Syrabolic_Addres  s , 

<<  L2  >> 

«  L3  >> 

<<  L4  » 

■will  produce  a  code  sequence  like 

LI :  .word  L2 

.word  L3 
.word  L4 

DATA6  4  is  used  to  place  a  64-bit  piece  of  data  into  cbe  code  stream.  The  only  legal  operand  is  a  floating 
literal  (i.e.,  the  operand  whose  address  mode  is  FLOATIMM). 

5.10.9.  Inline  Expansion 

Routines  which  contain  machine  code  inserts  may  be  inline  expanded  into  the  bodies  of  other  routines.  This 
may  happen  under  user  control  through  the  use  of  pragma  INLINE,  or  with  optimizations  fcH’  standard  and 
nmeopdmizadon  levels  when  the  compiler  selects  that  optimization  as  an  appropriate  action  for  the  given 
situatitML  The  compiler  will  treat  the  machine  code  insert  as  if  it  were  a  calL  Volatile  registers  will  be  saved  and 
restored  around  it  a^  similar  optimizing  steps  will  be  taken. 

5.10.10.  Move  Macro  Instructions 

The  C40  instruction  set  contains  no  single  all-purpose  move  instruction,  but  instead  supplies  the  set 
{ LOI ,  LOF ,  STI ,  STF } .  Each  of  these  instructions  defines  a  very  specific  kind  of  move  with  restrictions  on 
dau  types  and  source/destination  locations  (memory  vs.  register).  Unfominately.  when  constructing  dau  moves 
using  package  MACHIN£_CODE.  it  is  impossible  to  predict  if  an  Ada  objea  will  be  in  memoiy  or  in  a  register, 
especially  in  the  presence  of  inlining.  For  this  reason,  three  "macro"  instructions  are  supplied: 


Name 

Meaning 

MOVI 

MOVF32 

MOVF40 

Move  a  32-btt  integer  firom  the  first 
operand  to  the  second,  emitting  some 
combination  of  LDI  and  STI’s  to  do  so. 
Move  a  32-bit  float  from  the  first 
operand  to  the  second,  emitting  some 
continnation  of  LOT  and  STFs  to  do  so.  ' 
Move  a  40-bit  float  from  the  first 
opetaml  to  the  second,  emining  some 
combination  of  LDF/LDI  and  STF/STI’s  to 
do  so. 

L2'. Address' , 
L3'.Aaaress)  , 
L4' Address) ) ; 


5.10J.  1.  Using  lAJ  instructions 

The  code  generated  for  a  routine  written  in  Ada  has  two  entry  points.  One  of  the  entry  points  is  used  by 
CALL  instructions.  The  other  entry  point  is  used  by  LAJ  instructions.  The  example  below  sh^  the  two  code 
sequences  that  the  compito'  can  generate  for  a  given  tontine: 
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?C?  .^11  ;  CALL  er.cry 

....  ;  LAJ  entry 

3U  All 

_nyfuncSLAJ:  PUSH  Rll  ;  LAJ  entry 
_myfunc;  ....  ;  CALL  entry 

RETSU 

Two  groups  of  LAJ  instructioas  are  provided  in  package  MACHINE_COCE.  The  special  group  of  LAJ 
instructions  that  has  the  _.Ada  suffix  should  be  used  to  call  routines  that  are  written  in  Ada.  Using  one  of  these 
special  LAJ  instiuctiaas  tells  the  compiler  that  the  target  of  this  call  should  be  the  LAJ  entry  of  the  routine  and 
not  the  CALL  entry  of  the  routine.  If  an  LAJ  without  the  _Ada  suffix  is  used,  the  compiler  will  use  the  CALL 
entry  of  the  roudne  as  the  target.  The  non  __Ada  vetsioD  should  be  used  to  call  routines  that  are  not  written  in 
Ada  (i.e..  routines  that  are  written  in  assembly,  C,  etc.). 

Calling  the  Ada  routine 

One_Opnds'  (LAJ_Ada,  {Symbolic_^Address,  My_Ada_Function' Address) ; 
will  produce 

LAJ  _myadafuncSLAJ 

where  the  compiler  uses  the  LAJ  entry  of  My_Ada_Function  as  the  target 
Calling  the  Assembly  routine 

One_Opnds' (LAJ,  (Symbolic_Address,  My_Assembly_?unction' Address) ; 
will  produce 

LAJ  _myassemblyfunc 

and  not 

L.AJ  _myassetnbiyfuncSLAJ 

because  the  CALL  entry  of  MY_ASSEMBLY_t  UNCTION  is  used  for  the  non  _Ada  LA  Js. 

If  the  source  operand  of  a  LA  JCONO_AOA  instruction  is  a  register  then  the  compiler  cannot  generate  the  LAJ 
entry  for  the  routine.  An  error  message  is  issued  in  this  case.  An  Ada  routine  can  be  called  by  LAJCOND 
instructions  whose  source  operand  is  a  register  if  the  not  _Ada  versioa  is  used.  The  following  exan^le  shows 
how  Ada  routines  can  be  called  by  LAJCOND  instrucdons  that  have  a  register  as  the  source  operand. 


Tiyrunc : 
niyfuncsLAJ : 
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Two_Cpncis'  (LDIU, 

One_Opnds' (LAJU, 
Two  Opnds' (LDIU, 
Two'Opnds' (LDIU, 
One_Opnds' (PUSH, 


(3ymboiic_Acdress,  My_Ada_runczicr/ . -.caress )  , 

(Reg,  .\RC)); 

(Reg,  ARO));  —  use  che  non  _Ada  version 
(Imm,  1),  (Reg,  RO).); 

(I.TOT,  1),  (Reg,  Rl)); 

(Reg,  Rll) ) ;  —  return  address  is  pushed  on  stack 


will  produce 


LDIU  @DEF1,  ARO 
LAJU  ARO 
LDIU  1,  RO 

LDIU  1,  Rl 

PUSH  Rll 


DEFl:  .word  _myadafunc 

In  the  above  ^Trample  tfae  target  of  tbe  LAJU  will  be  the  CALL  entry  for  MY_ADA_F UNCTION  and  not  the  LAJ 
entry.  Since  the  target  of  tbe  LAJU  is  tbe  CALL  entry,  the  renim  address  must  be  pushed  onto  the  runtime  stack 
to  simulate  tfae  semantics  of  a  CALL  instrucdon.  This  is  Hone  by  making  die  PUSH  Rll  fill  tbe  last  delay  slot  of 
the  LAJU. 


5.10  J2.  Unsafe  Assumptions 

There  are  a  variety  of  assumptions  stdiich  should  not  be  made  when  writing  machine  code  inserts.  Violation 
of  these  assumpdons  may  result  in  the  generadon  of  code  s^cb  does  not  assemble  or  which  may  not  fimcdon 
conecdy. 

•  The  compiler  will  not  generate  call  site  code  for  you  if  you  emit  a  CALL  or  LAJ  instrucdon.  Yon  must 
save  and  restore  any  volatile  regisien  which  currently  have  values  in  them,  etc.  If  tbe  routine  you  call  has 
out  parametBTS.  a  large  fimcdon  return  result,  or  an  unconstrained  result,  it  is  your  responsibility  to  emit 
tbe  necessary  instrucdons  to  deal  with  these  constructs  as  tfae  cooq>iler  expects.  In  other  words,  when  you 
emit  a  CALL  or  LAJ,  you  must  follow  tbe  linkage  convendons  of  tfae  routine  yon  are  calling.  For  fiirtber 
details  on  call  site  code,  see  Secdons  6.4. 6  J  and  6.6. 

•  Do  not  assume  that  tfae  '  ADDRESS  on  SYMBOLIC_ADDR£SS  or  SYMBOLIC_VALUE  operands  means 
that  you  are  getting  an  ADDRESS  to  ogenxe  on.  The  Address-  or  Value-ness  of  an  operand  is  determined 
by  your  choice  of  SYMBOLIC_ADDRESS  or  SYMBOLIC_VALUE.  This  means  that  to  add  tbe  contents  of 
X  to  ARO.  you  should  write 

Two_Opnds'  (ADDI,  (Syinbolic_Value,  X'ADDRESS), 

(Reg,  ARO) ) 

but  to  add  tfae  address  of  X  to  ARO.  you  should  write 

Two_Opnds' (ADDI,  (Syinbolic_Address,  X'ADDRESS), 

(Reg,  ARO) ) ; 


5.10  J3.  Limitations 

The  cnrrem  implementadcn  of  tfae  compiler  is  unable  to  fully  support  automatic  oonecdon  of  certain  kinds  of 
operands.  In  pardcnlar.  tbe  compiler  asnroes  tliat  tbe  size  of  a  dm  object  is  tfae  same  as  tbe  number  of  bits 
which  is  operated  on  by  tfae  instrucdon  cfaosen  in  the  machine  code  insen.  Hiis  means  diat  die  insen 

Two_<3pnds' (ADDF,  (Symbolic  Value,  Long_Float_Variable' ADDRESS) , 

(Reg,  RO)) 

will  not  generate  cocrea  code  when  LONG_FLOAT_VARlABLE  is  bound  to  memory.  The  compiler  will  aaaonm 
that  LONG  FLOAT^VARIABLE  is  32  bits,  when  in  fimt  it  is  stored  in  64  bits  of  memory.  If.  on  tbe  other  hand. 
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LCNG_rlCAr_7ARIABLZ  was  bound  to  an  extended-precision  register,  the  mserdon  will  function  properly,  as 
no  collection  is  needed. 

Note  tiiat  tbe  use  of  X'  i\DCR£SS  in  a  machine  code  insert  does  not  guarantee  that  X  will  be  bound  to 
memory.  This  is  a  result  of  the  use  of  '  ADDRESS  to  provide  a  “typeless”  method  for  naming  Ada  objects  in 
machine  code  inserts.  For  example,  it  is  legal  to  say  (SYMB'OLIC_VALL'E,  X' ADDRESS)  in  an  insen  even 
when  X  is  found  in  a  register. 

5.10.14.  Example 

with  :iiachine_code;  use  machine_code; 
procedure  n»ach_example  is 

type  ary_type  is  array(1..4)  of  integer; 

a:  ary_type  :•  (1,2, 3,4); 
b:  integer; 

procedure  case_statement (a:  in  integer;  b:  in  out  integer)  is 
begin 

—  implements  case  a  is 

when  1  ->  b  :•  0; 
when  2  ->  b  b  ♦  1; 

—  when  3  ->  b  :■  b  •  b; 
when  others  ->  null 
end  case; 

Three_Opnds' (SUBI3,  (Imm,  1),  (Symbolic_Value,  a'Address),  (Reg,  IRO)); 

Two  Opnds'iLDI,  (Symbolic  Address,  Ll'Address),  (Reg,  ArO)); 

Two“opnds' (LOI,  (IPrIA,  ArO,  IRO),  (Reg,  ArD);  •  ' 

One~Opnds' (case_jump,  (Reg,  ArD); 

«  LI  »  “ 

Three_Opnds' (DATA32,  (Symbolic_Address,  L2'Addre3s), 

(Symbolic~Address,  L3'Addres3), 

(Symbolic_Address,  L4' Address) ) ; 

«  L2  » 

Two_Opnd3' (LDI,  (Imm,  0),  (Symbolic_Address,  b' Address)); 

0ne~0pnd3' (BU,  (PcRel,  L5' Address) ) ; 

«  L3  » 

Two_Opnds'  (ADDI,  (Imm,  1.),  (Symbolic_Value,  b'.Address)  ) ; 

One_Opnds' (BU,  (PcRel,  L5' Address) ) ; 

«  L4  » 

Two  Opnds' (MPYI,  (Symbolic_Value,  b' Address),  (Symbolic_Value,  b' Address)) 
«  L5  »  ~ 

2ero_0pnd3' (NOP) ;  —  since  label  can't  be  last  statement  in  procedure 

end  case_statement; 

pragma  INLINE (case_statement) ; 

begin 

if  a(l)  >-  0  then 

case_3tatement (a(3) ,  b) ;  —  will  be  inline  expanded 

end  if; 


end  mach_example; 
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Assembly  code  output: 


.global 

nach_example 

.global 

AO Omchxmp 1 0 0 0 9 

.global 

AO Omchxmp 1 0 0 0 9 S LA J 

.  text 

AO Omchxmpl 0 0 0 9 : 

POP  Rll 

A0Omchxmpl0O09SLAJ:  ADDI  1 

.SP 

PUSH 

AR3 

LDA 

SP,AR3 

PUSH 

AR3 

ADDI 

4,SP 

PUSH 

R5 

PUSH 

R8 

LDA 

9DEF1,AR0 

STI 

ARO, •+AR3 (1) 

LDA 

3DEF2,ARO 

;  line 

1 

AODI3 

2,AR3,AR1 

LOIU 

*AR0++(1) ,R1 

RPTS 

2 

LDI 

•AR0++(1)  ,R1 

1  1  STI 

R1,*AR1>+(1) 

STI 

Rl,  'ARl 

CMPI3 

0,  ••■AR3  (2) 

;  line 

43 

BLT 

L22 

LOIU 

*fAR3 (4)  ,R0 

;  line 

44 

LDIU 

R5,R8 

LDIU 

R0,R5 

SUBI3 

1,R5,IR0 

;  line 

13 

LDI 

3DEF3,ARO 

;  line 

19 

LDI 

•+AR0 (IRO) ,AR1 

;  line 

20 

au 

ARl 

line 

21 

L23: 

L14: 

.word 

LIS 

;  line  23 

.word 

L16 

.word 

LIT 

L15: 

LDI 

0,R8 

line 

27 

BU 

L13 

line 

28 

L16: 

ADDI 

1,R8 

line 

30 

BU 

LI  8 

line 

31 

L17: 

MPYI 

R8,R8 

line 

33 

L18: 

NOP 

line 

35 

LDIU 

R8,R5 

line 

44 

L22: 

LOIU 

;  line  40 
•-fAR3(6)  ,R5 

LOIU 

•■■AR3  (7)  ,R8 

BUD 

Rll 

LDA 

AR3,SP 

POP 

AR3 

SUBX 

1,SP 

;  Total  words  of  code  in  the  above  routine  •■41 

.text  .‘assigned  to  "DEFALT*  data  page 
. sect  *  o : DEFALT* 

DEF3:  .word  LI 4 
DEFl:  .word  L22 
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.  text 

casestatementSOO ;  ?CP  Rll 

casestatemencSOOSLAJ: 


SU  Rll 


;  Total  words 

of  code  in  tiie 

above  routine 

-  2 

.  text 

; assigned  to 

"DEFALT"  data 

page 

.  sect 

"o:DEFALT" 

.  text 

; assigned  to 

"DEFALT"  data 

page 

.  sect 

"o: DEFALT" 

DEFALT:  .word 

0 

.  text 

.  te.xt 

;  assigned  to  "DEFALT"  data  page 

.  sect 

"o: DEFALT" 

DEF2: 

.word 

DEF5 

DEF5: 

.word 

1 

.word 

2 

.word 

3 

.word 

4 

;  Total 

words 

of  code  *43 

;  Total 

words 

of  data  ■  ~ 

end 
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5.11.  INUNE  GUIDELINES 

The  following  discussion  oo  inlining  is  bued  on  the  next  two  examples.  From  thei^  sample  programs, 
general  rules,  procedures,  and  caudons  are  illustrated. 

Consider  a  package  with  a  subprogram  that  is  to  be  inlined. 

package  IN_PACK  is 

procedure  I_WILL_3E_INLINED; 
pragma  INLINE  (I_WILL_aE_INLINED) ; 
end  IN_PACK; 

Consider  a  procedure  dut  makes  a  call  to  an  iniinerf  subprogram  in  the  package, 
with  IN  PACK; 

procedure  USES_INLINED_SUB?  is 
begin  ~ 

I_WILL_BE_INLINED ; 
end;  ~ 

After  the  package  spedficadon  for  IN_PACK  has  been  compiled,  it  is  possible  to  compile  the  unit 
USES_INLINEO_SUBP  that  makes  a  call  to  the  stAprogram  I_WILL_BE_INLINED.  However,  because  the 
body  of  die  subprogtam  is  not  yet  available,  the  generated  code  will  not  have  an  iniinerf  versioo  of  the  sub¬ 
program.  The  generated  code  will  use  an  out  of  line  call  for  I_WILL_BE_INLINED.  The  eampiler  will  issue 
warning  message  #2429  that  the  call  was  not  inlined  when  USES_INLINED_SUBP  was  compiled. 

If  IN_PACK  is  used  across  libraries,  it  can  be  exported  as  pan  of  a  spedficadon  library  after  having  compiled 
the  package  specification.  Note  that  if  only  the  spedficadon  is  exported,  there  will  be  no  e»iu  » 

IN_PACK  in  all  units  within  libraries  that  impart  IN_PACK  .  If  only  the  qiedficadon  is  exported,  all  that 
appear  in  other  libraries  will  be  out  of  line  calls.  The  compiler  will  issue  warning  message  #6601  to  indicate  the 
call  was  not  inlined. 

There  is  no  warning  at  link-time  that  subptogiams  have  not  been  ini»n«>rf 

If  the  body  for  padtage  IN_PACK  has  been  compiled  before  the  call  to  I_WILL_3E_INLINED  is  compiled, 
the  compiler  will  inline  the  subprogram.  In  die  example  above,  if  the  body  of  IN  PACK  has  been  conned 
before  USES_INLINEO_SUBP.  the  call  will  be  inlined  when  USES_INLINED_SUB'p  is  compiled. 

Having  an  iniifwvt  call  to  a  subprognun  makes  a  unit  dependem  on  the  unit  that «««««"«  the  body  of  the 
subprogram.  In  the  example,  once  USES_INLINED_SUBP  has  been  compiled  with  an  inlined  call  to 
I_will_BE_INLINEO.  the  unit  (;SES_INLINEO_SUBP  will  have  a  dqieadency  oo  the  packa^  body 
IN_PACK.  Thus,  if  the  body  for  package  body  IN_PACK  is  recompiled.  USES_INLINED_SUBP  will  became 
obsolete,  and  must  be  recompiled  before  it  can  be  linked. 

It  is  poasibie  to  export  the  body  for  a  library  unit.  If  the  body  for  package  IN_PACK  is  added  to  the 
specification  library  using  the  Ada  libraiian  subcommand  EXPORT  LIBRARY,  other  libraries  that  import  pack- 
age  IN_PACK  will  be  able  to  compile  inlined  calls  aooa  library  units. 

At  optimization  levels  lower  than  the  default,  the  compiler  will  not  inline  calls,  even  when  pragma  INLINE 
has  been  used  and  the  body  of  the  subprogtam  is  in  the  library  ixior  to  the  unit  that  makes  the  call.  Lower 
optimization  levels  avoid  any  <*«Bge«  in  flow  of  the  code  that  canaes  movement  of  code  sequences,  u  happens  in 
a  pragma  INLINE.  If  the  compiler  is  running  at  a  low  optimization  leveL  die  user  will  not  be  warned  that 
tniining  is  not  happening. 

See  Section  7.12  for  a  method  to  control  inlining. 
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